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ABSTRACT 



In the early stage of the Weapons Acquisition Process (Concept Exploration and 
Concept Demonstration'Validation Phases) no exact and reliable data are available 
about expected Mean Times Between Failures (MTBF) and Mean Times to Repair 
(MTTR) for both the components of a new system or the new system itself. Neverthe- 
less, appropriate decisions have to be made about the number of maintenance facilities 
at certain military' command levels, about the needed quantity of (militar\' and/or civil- 
ian) maintenance personnel, and about adequate spare stock levels at the appropriate 
locations. 

Wrong planning in this early stage can cause a degradation of the new system's fu- 
ture availability. This is problematic especially with electronic equipment, because 
maintenance personnel have to be highly specialized, and can not be replaced and re- 
trained as easily as support personnel for trucks or tanks. 

decision aid for the early stages of the acquisition process is needed that offers 
insight into the behavior of a multi-indenture level electronic system within a three ech- 
elon maintenance system, develops alternatives for upcoming decisions, and finally pro- 
vides information about sensitive factors and their possible tradeoffs, essentially used in 
budgetar>' discussions. 

The purpose of this thesis is the exact definition of all relevant factors pertaining to 
the necessar}' decisions, the review of existing models and tools and their review for ap- 
plicability. Because the modification of existing programs can not solve the whole scope 
of the problem due to the use of early generation computer languages, and due to the 
necessarily new and different approach to the topic, a new simulation program has to 
be developed. Using object oriented simulation language MODSIM-II, first steps to- 
wards this program are made, but remain to be improved and completed in further re- 
search work. 
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THESIS DISCLAIMER 

The reader is cautioned that the computer program developed in this research 
(MODSIM Definition and Implementation Modules) have not been exercised within a 
complete program. While every effort has been made, within the time available, to en- 
sure that the modules are free of logic errors, they are incomplete and can not be con- 
sidered validated. Any application of these modules in a MODSIM-program without 
additional verification is at the risk of the user. 
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I. INTRODUCTION AND PROBLEM STATEMENT 



A. LOGISTIC SUPPORT IN THE WEAPONS ACQUISITION PROCESS 

In the Weapon Acquisition Process, both within the U.S. Armed Forces and within 
the Federal Armed Forces Germany, the planning for providing sufficient and efficient 
logistic support for a new weapon system begins in the early stage, in the Concept Ex- 
ploration Phase and the Concept Demonstration/Validation Phase. Quantity and quality 
of maintenance personnel, maintenance facilities, spare and exchange parts, storage fa- 
cilities, tools, manuals and training have to be determined as early as possible, because 
the lead time from planning to acceptance by budgetary commissions, from contracting 
parts and tools to actual deliveiy, and from hiring personnel until their final ability to 
repair defective equipment is nearly as long as the actual development time of the oper- 
ational weapon system itself Using the concept of Integrated Logistic Support (ILS 
[Ref 1]), this problem is addressed in the U.S. Army. Nevertheless, it is not uncommon 
that militarv' equipment is deployed to the active forces without sufficient logistic sup- 
port. One reason is based on the fact that reliable data for computing necessary and 
adequate quantities for logistic support facilities are not available at that point of time 
they are needed. 

B. SPECIAL SITUATION WITH ELECTRONIC MATERIEL 

Although the personnel training problem with conventional equipment (i.e. equip- 
ment based on mechanical, electrical or weapons engineering) can be managed by reas- 
signing existing manpower to a new system after some time for training, this problem is 
more crucial for electronic materiel. Complex and expensive equipment needs thoroughly 
trained and highly specified personnel. So it is essential to avoid delays in the planning 
process, caused by w’aiting for the availability of data. The approach developed in this 
thesis concentrates on electronic equipment. 

C. PRELIMINARY DECISIONS BASED ON EXPERIENCE 

For computing the number of maintenance personnel for any new weapon system within 
a given military' maintenance structure, two equipment specific data are essential: 

• Mean Time Between Failures (MTBF) 

• Mean Time To Repair (.MTTR) 
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But at that crucial point of time in the Weapons Acquisition Process, at which numbers 
are needed to get started in time, no data are available about MTBF and MTTR for the 
components of a new system. Even the system itself will not be defined in any precise 
form. There will be functional units with defined abilities, there ■will be components with 
a known technology, there will be first details of a redundancy concept. 

But already in the first Acquisition Decision Memorandum (ADM) at the end of the 
Concept Exploration Phase, numbers for quantities are entered. Based on the knowledge 
of experienced personnel, these numbers are not necessarily wrong. In fact, these initial 
numbers often turn out to be pretty close to reality. But there is an inherent danger of 
offering data that can not be justified. In times of economic constraints requests based 
on intuition generally are not accepted by budgeteers. So the initial numbers are adjusted 
to budget shortages without having any clue about the sometimes fatal consequences for 
the logistic support system, just because these initial numbers can not be backed by any 
kind of analysis. 

D. THESIS OVERVIEW 

Operations Research methods seem to be an appropriate way to resolve this situ- 
ation. Formulating the given problem as a stochastic model and applying adequate es- 
timation and calculation methods should offer numbers, w^hich can be analyzed for 
sensitivity about changes of all kind, and can not be rejected solely due their intuitional 
origin. 

In proceeding towards this goal, the following steps are performed in this thesis: 

• In Chapter II, the overall problem is described. This includes a presentation of the 
military environment with emphasis on the support of future electronic weapon 
systems. Figures I and 2 illustrate both the design structure of a future electronic 
system and the command structure of its area of deployment, the Federal Armed 
Forces Germany. Figures 3 and 4 visualize those places in the military environ- 
ment, where both structures meet - the different kinds of military maintenance fa- 
cilities. Finally, all facts, rules, subtleties and interactions pertaining to the 
maintenance problem are described. 

• Chapter III starts with a review of published analytic models and results related to 
theoretical maintenance problems. These models are either designed to solve dif- 
ferent problems, or they are purely analytic in nature and tend to describe idealized 
systems. Section C of Chapter III describes the basic flow model that is studied in 
this thesis, and which is shown in Figure 6. 

• Because of the complexity of the interaction between a four-indenture-level weapon 
system and a three-echelon maintenance system, simulation of stochastic processes 
is used as the primar\‘ modeling tool. Chapter IV contains an overview of available 
simulation models, with emphasis on "TIGER", a FORTRAN-based program used 
by the Naval Sea Systems Command in the U.S.Navy. 
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• Due to the fact that there is no directly applicable simulation model for the given 
problem, Chapter V shows the necessary input modifications in the use of TIGER 
to obtain useful results for the decisions to be made. 

• Chapter VI contains the results of the application of TIGER, and describes its 
major shortcomings when used for the given problem. Basically it can offer only a 
fixed number of input choices (due to the computer language used), restricting the 
user to small weapon systems, and it does not enable the modeling of the back-flow 
of repaired components of repaired systems to their respective stocks. 

• It appears that these problems could be overcome by using a modern, object- 
oriented simulation language like MODSIM-II. Chapter VII describes how 
MODSIM can be used for solving the given problem, and shows compiled code for 
some of the objects in Appendix C. A full-scale-development of a simulation model 
for the complex real two-system-interaction world is beyond the scope of this the- 
sis. 

• This thesis ends with suggestions in Chapter VIII for the necessary future work to 
be done on this topic, which might help both to increase the efficiency of the lo- 
gistic part of the Weapon Acquisition Process and to improve the management of 
the available financial resources within the defense budget of the Federal Republic 
of Germany. 
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II. THE MILITARY ENVIRONMENT OF THE UPCOMING DECISION 



In this chapter the militar>’ environment of the decision model is defined by pre- 
senting 

• the modular structure of electronic equipment, applied in the weapons acquisition 
process of the Federal Armed Forces Germany 

• the general maintenance concept to provide support to these electronic systems in 
the German Army[Ref 2) 

• the command structure of the German Army with combat, combat support, com- 
munication and logistic forces. 

A. MODULAR STRUCTURE OF ELECTRONIC EQUIPMENT 

Electronic weapon systems in the notation of the German Armyl include weapon 
systems with essentia! electronic components (e.g. battle tanks with an electronic 
weapon guidance system, Artillery weapons controlled by a data link system), command- 
and control systems, signal- and communication systems (e.g. AUTOVON (US) / 
AUTOKO (GE)), reconnaissance systems (e.g. Artillery reconnaissance radar) and sig- 
nal- and comntunication- intelligence systems. .All these electronic weapon systems are 
generally structured in 5 indenture levels^ as seen in Figure 1 on page 5: 

1. The complete system itself - as an illustrative e.xample we will look at a Bailie Tank 
assumed to be developed. 

2. Subsystems or A-Units are functional units or self contained units within a weapon 
system. In our example the (non-electronic) Gun, the (electronic) Weapon Guidance 
Subsysiem, the (electronic) Command- and Conirol Subsysiem and the ("semi"- 
electronic) Power Supply Subsysiem are .A-L’nits. 

3. Assemblies or B-Units are integral parts of A-Units. Targei Daia Storage and Data 
Display Terminal are B-Units of the Command- and Control Subsysiem. 

4. Subassemblies or C-Units and 

5. Elements or D-Units are both the smallest replaceable components of a weapon 
system. The "black box" Updated Target Data Memory is a C-Unit (subassembly) 
that will not be repaired in the field, the Microchip A4512 is a D-Unit (element) that 
can not be repaired at all. 



1 This structure is slighth' different from that used by the US Army in the Logistic Support 
Analysis (LSA) procedures (Ref. 1, p.2-17). 

2 The term indenture level is also used by the US Army to address the different levels of a 
"hardware generation breakdown" (Ref. 1, p. 2( 
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Figure 1. Modular Structure of Electronic Equipment in the German Army 

B. MAINTENANCE CONCEPT FOR ELECTRONIC EQUIPMENT 

In general, the maintenance of any electronic weapon system is performed both by 
military personnel for conventional technology (engine, steering system etc.) and by 
militaiy personnel for electronic technology. In this paper we concentrate only on the 
maintenance concept for electronic equipment, shown in Table 1 on page 6 [Ref 2]. 
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Table 1. MAINTENANCE CONCEPT FOR ELECTRONIC MATERIEL 



Level of 
System 
Structure 


Test Procedure 


Maintenance Procedure 


System 


User (Notation in the German Army: Maintenance Echelon 1) 


Built-In-Test-Equipment (BITE) 
Technical .Manuals 


Report of defective A-Unit to 
Organizational Maintenance 


A-Units 


On- System modular maintenance 
bv replacement of Line Replacea- 
ble Units (LRU): B-Units; C- 
Units and D-Units if appropriate 


Organizational Maintenance (Maintenance Echelon 2) 


B-Units 


LRU-Test by Test, Measurement 
and Diagnostic Equipment 

(TMDE) / Technical Manuals 


Off-System modular maintenance 
of defective LRU by replacement 
of C-Units and D-Units 


Intermediate Maintenance (Maintenance Echelon 3) 


C-Units 


Technical Manuals, Contractoi 
manuals, special equipment 


Repair of C-Units by replacement 
of D-Units 


Depot Maintenance (Maintenance Echelon 4) or commercial mainte- 
nance (Maintenance Echelon 4) 


D-Units 


no test - no repair - recycle or discharge 



C. MILITARY COMMAND STRUCTURE OF THE GERMAN ARMY 

Germany is undergoing extensive political, economical and social changes since the 
unification on October 3rd 1990. As a consequence, the military structure of the Federal 
Armed Forces is subject to changes in the years ahead. The structure presented in the 
next paragraphs is the general structure of the Army, which will persist whatever 
changes and reductions might occur. Specific details and exact quantities are omitted 
since they are irrelevant for the stated decision problem. 

1. Combat, Combat Support and Communication Forces 

The highest command level below the Federal Ministry' of Defense, Headquarter 
of the Army, at BONN is an Army Corps. The general command structure of an Army 
Corps3 is shown in Figure 2 on page 7. 



3 There are 3 Army Corps in the German Army 
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Figure 2 . Command Structure of a German Army Corps 
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While an electronic weapon system used in the Combat Forces is mostly de- 
ployed in large numbers (e.g. there will be some thousand battle tanks wth electronic 

subsystems), the many different electronic weapon systems deployed in the combat 

/ 

support and communication forces often consist of only a small number of units (e.g. 
there will be only some 15 units of a communications- and signal-intelligence-system 
within the entire Army). 

2. Logistic Forces (Maintenance Component) 

The structure of the maintenance component is presented completely, but the 
supply component is shown only as far as it is under operational control of the mainte- 
nance component. 

a. Organizational Maintenance 

Organizational Maintenance (Maintenance Echelon 2), both for conven- 
tional materiel and for electronic materiel (EloMat), is provided by a Maintenance 
Platoon for every Batallion, and by a Maintenance Group for every Company that is 
not under operational control of a Batallion (See Figure 3). 
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Figure 3. Structure of the Organizational Maintenance 
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The quantity of the maintenance personnel is determined by the needed capacity, but 
at least 1 soldier has to be available at each Batallion Company for each type of weapon 
system. There is no supportive exchange of maintenance personnel between 
Batallions Companies. The skill-level has "only" to be appropriate for localizing defec- 
tive LRU4 by using BITE or straightforward traditional techniques, and for replacing 
them. Jobs requiring higher qualifications might be completed, if the personnel can per- 
form them with the available tools and within the capacity limits of the uniu 
b. Intermediate Maintenance 

The structure of the Maintenance Troops 5 (Maintenance Echelon 3) is 
shown in Figure 4 on page 10. 

Each Army Corps has 2 active Maintenance Batallions, servicing both the 
conventional materiel and the electronic materiel (EloMat) of the Corps' Combat Sup- 
port Forces and Communication Forces. Each Division has 1 Maintenance Batallion; 2 
Companies service the conventional materiel of the Division's Combat Support Forces 
and Communication Forces; 1 Company for electronic materiel services both the Divi- 
sion's troops and the electronic materiel of the Brigades - though ever}' Brigade has its 
own .Maintenance Company, there is no service for electronic materiel on the Brigade's 
command level. 

The quantity of the maintenance personnel is determined by the needed ca- 
pacity and the number of different fields of technology applied in the new system ("pure" 
electronic, optronic, Laser, Radar etc.). Many jobs are performed by mobile mainte- 
nance teams, and at least 2 soldiers have to be available at each .Maintenance 
Batallion Company (Elo.Mat) for each type of supported electronic weapon system 
and or each technology used. There is no supportive exchange of maintenance person- 
nel between Corps and or Divisions. Though localization of defective C- and D-L’nits 
for certain systems is performed by different personnel applying the complex Test, 
.Measurement and Diagnostic Equipment (T.MDE), the skill-level generally has to be 
appropriate for localizing defective C- and D-Units using traditional techniques, and for 
replacing these units. Again, jobs requiring higher qualifications might be completed, if 
the personnel can perform them with the available tools and within the capacity limits 
of the unit. 



4 See pages xi and xii for a List of Abbreviations and Acronyms 

5 based on the actual structure of the .^rmy in the 10 Western States of Germany (the former 
West Germany) 
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Figure 4. Structure of the Maintenance Troops 
c. Depot Maintenance 

Materiel with damages requiring work in Maintenance Echelon 4 leaves the 
combat zone and is transported to central repair shops at Army Maintenance Installa- 
tions, at depots or at commercial facilities. 
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d. Interactions 

While personnel of the Organizational Maintenance might perform jobs of 
a higher Maintenance Echelon if capacity constraints, skill levels and available tools al- 
low, maintenance teams of the Maintenance Troops can be ordered by their operational 
command to work on surplus jobs on Maintenance Echelon 2, if this is the only way to 
increase the availability of a certain electronic system at a certain military unit. How- 
ever, this regulation wiU not be regarded in this model, because it should be constrained 
to emergency situations. 

e. Replacement Parts Supply and Storage 

All considerations about replacement of LRU (B-Units/Assemblies) at 
Maintenance Echelon 2 and C- (Subassemblies) and D-Units (Elements) at Maintenance 
Echelon 3 are based on the immediate availability of replacement parts at these mainte- 
nance facilities. Supply of these parts only on demand would take far too long to guar- 
antee shortest possible times to repair. 

To decrease the down time of a weapon system, each .Maintenance Batallion 
(intermediate maintenance level) has a Direct Exchange Stock (DES) for B-Units, and 
if appropriate, also for selected C- and D-Units (see Table 1 on page 6). The military 
user delivering a defective B-Unit immediately receives, if available, an intact B-Unit in 
exchange, while the defective B-Unit will be added to the DES after repair. So the 
downtime for a B-Unit (consequently the downtime of the failed system after being di- 
agnosed and before actually being repaired) is reduced to the amount of transportation 
time between military' user and its assigned .Maintenance Batallion. Of course, the 
.Maintenance Batallions also have a stock for the C- and D-Units needed for repair of 
the defective B-Units. 

Consequently, the model has to consider the necessary stock levels at the 
facilities of .Maintenance Echelon 2 and 3, but not further back in the line of supply 
which will be assumed to have unlimited capacity. 

D. CONSEQUENCES FOR THE UPCOMING DECISION 

Resulting from the facts presented above, certain range limitations for the following 
decision areas have to be observed; 

1. Organizational Maintenance 

Due to the concept of Organizational .Maintenance, each Batallion/Company 
supplied with a certain electronic weapon system has to be able to perform repair jobs 
on its own equipment at .Maintenance Echelon 2. So the decision to be made is not 
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about the fact of creating an installation at all, but "only” about the number of repair 
personnel, which will be at least 1 . 

To keep the Organizational Maintenance as highly mobile as the weapon system 
itself, a spare stock of A-Units generally will not be kept at the organizational level. 
However, establishing such a (limited) spare stock might be one way to increase the 
system availability, and can be one feature of the upcoming decision. 

2. Intermediate Maintenance 

Because some electronic weapon systems, especially those deployed in very small 
numbers, are designed to avoid any work at Maintenance Echelon 3, the number of re- 
pair personnel for a certain weapon system at Maintenance Echelon 3 might be 0. If 
Maintenance Echelon 3 is appropriate, there are several choices for the location of 
maintenance facilities. In Table 2 the possible mutual exclusive alternatives are shown. 
In these cases stock levels for both the DES (Direct Exchange Stock) and the C- and 
D-Units stock have to be determined. 



Table 2. MAINTENANCE FACILITIES AT MAINTENANCE ECHELON 3 



Command level of system de- 
ployment 


Number of maintenance facilities 


Sum for 
entire 
Army 


Brigade 


1 per Division 


12 


Brigade + Division 


1 per Division 


12 


Division 


1 per Division 


12 


Division + Corps 


1 per Corps 


3 


1 per Division and per Corps 


15 


Corps 


1 per Corps 


3 


Brigade + Division + Corps 


1 per Corps 


3 


1 per Division and per Corps 


15 



3. Depot Maintenance 

The decision about the quantity of the maintenance personnel at the depot level 
is not as important as at the organizational and intermediate level at this stage of the 
decision problem. Therefore this problem will not be addressed, nor that of spare stock 
levels at Depot Maintenance facilities which will be assumed to be infinite. 
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III. THE THEORETICAL BASIS FOR THE UPCOMING DECISION 



A. GENERAL APPROACHES FOR MAINTENANCE CONCEPTS 

A survey of the articles published in the respective journals within the last years 
shows numerous studies and papers about the modeling of optimal maintenance policies 
for single- and multi-unit electronic and non-electronic systems; for example see [Ref 
3, 4, 5, 6 and 7]. An overv'iew especially about models for multi-unit systems is given in 
[Ref 8]. 

These "... .Multi-unit maintenance models are concerned with optimal maintenance 
policies for a system consisting of several units of machines or many pieces of equip- 
ment, which may or may not depend on each other ... The objective is to find optimal 
repair rates (i.e., number of repairmen, number of repair facilities, etc.) ..."[Ref 8]. 

Many of these models consider specialties needed in the defined military environ- 
ment like 

• more than one repair facility in the system 

• failed equipment has to be sent to a certain repair facility 

• multi-echelon maintenance structures. 

So, the reader might ask, are we to invent the wheel again ? There are three main 
reasons for a different approach to solve the given real-world problem. 

1. Distributions for Failure and Repair Times 

In many models mathematical procedures are simplified by assuming an expo- 
nential distribution for both the times between failures and the repair times. Especially 
regarding electronic components having a high reliability, this assumption may be un- 
realistic for the times between failures. We will observe a high mean time between failure 
(MTBF) wnth ver\' few failure times being close to zero. Jardine and Buzacott [Ref 6 , 
p.286] even state that it is realistic to assume that there are no failures at all between the 
start-up of the observ'ed equipment (y = 0) and some time y > 0. 

The assumption of exponential distribution may or may not be realistic for the 
repair times. The exponential distribution for repair times says that the probability for 
completion of a repair job in the next k units of time does not depend on how long the 
repair job has been worked on already - not too realistic for some types of repair! There 
will be a minimum time for each repair job (receiving the job, preparing the work place. 
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performing test and measurement procedures, performing the genuine repair etc.). 
Though there will be no values close to zero, we will observe a highly skewed distribution 
with a lot of smaU TTR- values (caused by easy detectable mechanical or thermal dam- 
ages followed by simple replacement of the damaged component) and, nevertheless, a 
non-negligible number of observations with distinctive higher values (caused by short- 
circuits etc.). Though some studies (e.g. see in [Ref 8 ,p.5]) use general repair times, the 
assumption of exponentially distributed TTR seems reasonable, when the nature of the 
repair is random due to the random type of failure. 

2. Optimality Criteria 

Another great drawback is the use of all kinds of costs as optimality criteria to 
achieve an optimized maintenance concept. This is legitimate and appropriate in all de- 
scribed problems, especially in cases regarding not only costs for repair personnel and 
repair facilities, but also costs for spare part inventories and costs in form of lost reven- 
ues due to dow-ntimes caused by failures. While lost revenue is irrelevant in the military 
environment (though a lost battle has an enormous economic impact), most other types 
of costs are not applicable in the described real-world situation, because they are neither 
known nor can be acquired in this early stage of the acquisition process. 

Other models additionally or exclusively use the availability of the system as a 
decision criterion - for example see [Ref 7, p. 551]. This approach is promising pertain- 
ing to the given problem. 

3. Available Information 

Due to the fact that the future system is not defined exactly at this point of time, 
we have to make a decision under extreme uncertainty . Because we do not have any test 
results for single Subsystems, Assemblies or Subassemblies (with the exception of 
standardized equipment), we have to create, in the most controlled way possible, 
"probable probability distributions" for the times between failures for each proposed and 
yet to be developed component of the planned System Breakdown Structure (SBS). 
Based on this "solid ground", we have to come to a recommendation for the future 
maintenance concept for this new electronic equipment. 

Cho and Parlar [Ref 8, p.3] realize that dilemma by stating "... Very few papers 
have been written on the area of maintenance models with incomplete information ...". 
The need for further research on this field within the military environment is emphasized 
in a 1984 Notice of the Secretary of the Na\7, D.E. Marm [Ref 9, p.87j; "Although there 
is considerable uncertainty early in the acquisition process, every effort must be made 
to use the best available data and techniques in developing estimates." 
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B. IDEALIZED APPROACH FOR GIVEN PROBLEM 
1. Distributions for Time Between Failure 

Regarding possible failure scenarios and evaluating the actual literature (e.g. see 
(Ref. 6]), the Weibull and the Gamma distribution are the most appropriate to use for 
time between failure. 

The Weibull density function has the following form [Ref 6, 10 and 11], also 
used by the statistical package GRAFSTAT [Ref 12]: 

= (t)'"’ 5 0<r<oo,c>0,a>0 

and its cumulative distribution function has the form; 



The Gamma density function has the following form [Ref 13, p. 165, and 12]: 



m = 



t 



a-l 



r F(a) 



_ J_ 

e p ; 0</<oo, ]3>0, a>0 



Its cumulative distribution function can not be obtained in closed form. 

Using appropriate shape-parameters ("c" for the Weibull, "/?" for the Gamma) 
and scale-parameters (a), both distributions are highly flexible to fit Exponential and 
Normal distributions, and any other distribution being "humped in the middle". This 
"flexibility'' is shown in Figure 5 on page 16. 

Jardine and Buzacott [Ref 6] use the 3-parameter Weibull density function with 
the third parameter "y", the location parameter. This is not appropriate in our situation. 
Though the number of failures of one component occurring within a short time will be 
ver}' small, this possibility has to be regarded because there might be imperfect repairs. 
Pertaining to this fact many studies assume that repaired components are as good as new 
(e.g. in [Ref 7]), which will not be realistic in a military environment - neither in war nor 
in peacetime. Consequences of imperfect repair on system reliability are show'n in [Ref 
14]. 

So the approach to the given real-world problem described here will use either 
the 2-parameter Weibull or the Gamma distribution to model the time between failures 
and the exponential distribution to model the repair times. 



15 



DENSITY FUNCTIONS FOR FAILURES AND REPAIR 



WCOULL DtSTKIBUnON. ALPHA-720 





Figure 5. The Flexibility of the Weibull and Gamma Density Functions 

2. Links between Failure and Repair Times 

Many authors assume exponentially distributed repair times, but most of them 
also assume the same repair time distribution for all components which are subject to 
failure. This is partially unrealistic for the described problem. There is not only a differ- 
ence in repair times between changing a defective Subsystem in Organizational Mainte- 
nance (which can be assumed to be relatively constant due to "design to quick 
replacement"), and finding the defective Subassembly or Element within an Assembly 
when repairing it in Intermediate Maintenance (which could be covered by assumption 
of maintenance echelon specific repair times - a concept used by Madu in [Ref 3, p. 959 
- 960]), but there are also decisive differences in repair times between different technol- 
ogies at Intermediate Maintenance. Each specified component "X" of the future system 
will be characterized by 3 parameters; 

1. Cj.- value for the "probable" distribution for times between failures for component 
"X" (in case of the Gamma distribution the 

2 . a^-value for the "probable" distribution for times between failures for component 
"X" 
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3. MTTRx, the "probable" technology dependent MTTR for component "X" 

Pertaining to this necessar\' approach no literature at all was to be found. 

3. Source of Information 

With the future system just being defined in terms of a SBS (system breakdown 
structure), there are no data available for the necessar\’ values of 
Cx or ^xy 2 nd MTTRx- Jardine [Ref. 6, p.288] mentions three basic approaches to es- 
timate these data. While the third approach - models based on physical, chemical or 
other mechanisms of failure - is not appropriate due to the uncertainty of the engineering 
design at the relevant point in time, a combination of the other two approaches seems 
apphcable; 

1. Analysis of empirical data on a similar design 

2. Prediction of system reliability from component reliability 

With each single repair job done at Maintenance Echelon 2, 3 or 4 within the 
German Army, a lot of data are gathered offering information about the proceeding of 
the job over time. Active maintenance times (AMT = TTR = ART (Active Repair 
Time)) and the MTTR can be obtained directly. Administrative delay times (ADT), 
caused by maintenance system inherent procedures and geographical distances, and lo- 
gistic delay times (LDT), caused by ordering and waiting for spare parts not in stock at 
the maintenance facility can be estimated. Throughout the lifetime of each single weapon 
system, data are gathered about down times from which the times between failures 
(TBF) can be obtained. From these known TBF data the appropriate a, p and c-values 
can be obtained by using GRAFSTAT [Ref 12, "FITTING PROBABILITY 
DISTRIBUTIONS"]. 

Though we do not know the exact characteristics of the components of the fu- 
ture weapon system, we can assume that these values are not too different for compo- 
nents with similar functional characteristics (e.g. antennas, terminal keyboards, displays, 
RADAR-emitters, militar>' computers etc.) and within the same level of technology, 
which have already provided plenty of reahstic data from the actual use in the real 
(peacetime) world. Definite sources of trouble will be a differentiation of similar com- 
ponents originating from different contractors, the evaluation of offered "next technol- 
ogy' generation" components and the adaptation of the data to a wartime scenario 
(further research has to be done on these features). 
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If a totally new functional configuration will be introduced, the subcomponents 
still will offer a chance to find appropriate values, from which the reliability for the next 
higher SBS-level can be computed. 

4. Optimality Criterion 

As pointed out in 1 1 1. A. 2., system availability is one meaningful optimality cri- 
terion for evaluating future maintenance performance problems. This availability defi- 
nitely depends upon the reliabihty of the system, but can be increased decisively by an 
appropriate maintenance system. Before proceeding further, we need to recall the defi- 
nitions and characteristics of reliability and availability. 

• Reliability 

The probability that a weapon system will perform its intended function for a 
specified period of time under stated conditions [Ref 6, p.285, 15, p.32, and 16, p.20]. 

The reliability function R(t) is well defined as 



\"mdt 

where y(/) is the probability density function of the time between failures. Therefore the 
reliability function /?«,(/) for the general form of the Weibull distribution has the form 
(c> 0. a > 0): 







Although there is no closed form for the reliability function for the Gamma distribution, 
we could use the incomplete Poisson Sum for integer values of a to compute R(t). 

The reliability values obtained by this approach depend on 2 features: 

• the distribution of the times between failures, which is independent from the applied 
maintenance concept 

• the length of the specified period of time, which can be "varied to achieve any reli- 
ability value desired" {R -* Q ^or i -* oo, R -* 1 for r ->■ 0) 

Due to the independence from the maintenance concept, and due to possible 
bias by "conveniently" choosing the length of the time period, reliability is not suitable 
as an optimality criterion in the given problem. 
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• Availability 

The probability that a weapon system is in the operable state at any point of time 
when used under stated conditions[Ref. 15 , p.29 and 17, p.l9]. 

A generally used computational formulation of availability is the operational 
availability being defined [Ref 17] as 

. MTBM 

^ MTBM+MDT 

where MTBM is the Mean Time Between Maintenance and MDT is the Mean Down 
Time. MDT itself is the sum of MAMT (Mean Active Maintenance Time), LDT (Lo- 
gistics Delay Time) and ADT (Administrative Delay Time). Considering a long period 
of time this approach offers an average availability, which strongly depends - via MDT 
- on the applied system specific maintenance concept. However, MDT itself can not be 
handled as an average value, because this approach would not take into account worst 
case scenarios, where many components might fail within a short period of time, im- 
posing decisively more workload onto the maintenance system in some periods of time 
than under the mean value approach. 

This average availability is the appropriate optimality criterion for the given 
problem. Note that there is a decisive difference between the availability (combat readiness) 
of a military unit, and the availability of a single unit of a weapon system within this mili- 
tary unit. Only the latter will be covered here. 

C. THE STOCHASTIC MODEL OF THE MAINTENANCE SYSTEM 

The system specific maintenance system, determined by the number of deployed 
systems and introduced in l.B.,C. and D., can be described as a stochastic network, 
shown in Figure 6 on page 20 (See in comparison also [Ref 18, p. 18]). 

1. Fixed Parameters 

Its characterizing fixed parameters are defined in Table 3 on page 21. All given times 
are in hours, based on a (peacetime) average of 7 hours of use per day, 5 days of use per 
week and 48 of these weeks per year. E.g., ADT-^ = 35 means a delay of 35 hours of 
simulation time, which is about a week in peacetime, but 1 day and 1 1 hours in a war- 
time situation with a time of use of 24 hours a day, 7 days a week and 52 weeks a year. 
So these times are realistic for all possible scenarios. 

2. Decision Orientated Variable Parameters 

The variables shown in Table 4 on page 22 are the data upon which a decision 
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Figure 6. Stochastic Model of the Maintenance System 
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Table 3. FIXED PARAMETERS OF THE MAINTENANCE SYSTEM 



Parameter 


Value (hours) 


Description 


^Torcl 


These data 
can be ob- 
tained from 
the current 
Acquisition 
Decision 
Memoran- 
dum (ADM) 


Total number of systems deployed 




Number of systems deployed in one unit 


Uo 


Number of units per Division supplied with the sys- 
tem 


Dc 


Number of Divisions per Corps supplied with the 
system 


Uc 


Number of units under direct operational command 
of a Corps supplied with the system 


MART^ 


2 


.Mean Active Repair Time for an A-Unit by replace- 
ment of a B-Unit (see I1I.B.2.) or by performance of 
simple repair without replacement 


MART, 


2 - 14 


Active Repair Time for a B-Unit by replacement of 
C- and D-Units (error location and actual replace- 
ment) is dependent on the used technology 


LDZ,,,, 


1 


Number of delay hours caused by logistic delay per 
repair job in all Maintenance Echelons if required 
spare part is in stock at maintenance facility 


^^'^DES 


10 


Number of delay hours caused by logistic delay per 
repair job in Maintenance Echelon 2 if required As- 
sembly has to be obtained from DES at Intermediate 
.Maintenance 




35 


Number of delay hours caused by logistic delay per 
repair job in .Maintenance Echelon 3 if required spare 
part is not in stock, but available in the militaiy sup- 
ply line 


ADT, 


2 


Number of hours caused by administrative delay per 
repair job in .Maintenance Echelon 2 


ADT, 


35 


Number of hours caused by administrative delay per 
repair job in .Maintenance Echelon 3 (including trans- 
port times) 



a decision has to be made. Realistic values will be chosen as initial input data6, and will 
have to be readjusted for each new run of the simulation. 



6 What is realistic is determined by already known budgetary constraints, general personnel 
policies etc., and depends strongly upon the knowledge of an user experienced in his functional 
specialty. 
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Table 4. VARIABLE PARAMETERS OF THE MAINTENANCE SYSTEM 



Parameter 


Description 


R: 


Number of repair personnel at Maintenance Echelon 2 


(name) 


Number of spare parts of component "name" in stock at Mainte- 
nance Echelon 2 




Number of repair personnel at Maintenance Echelon 3 (Division) 


^ zDsTock (name) 


Number of spare parts of component "name" in stock at Mainte- 
nance Echelon 3 (Division) 


^3C 


Number of repair personnel at Maintenance Echelon 3 (Corps) 


(name) 


Number of spare parts of component "name" in stock at Mainte- 
nance Echelon 3 (Corps) 



3. Additional Variable Parameters 

Some militar>' performance requirements for a new system can be looked upon 
as variable parameters. If the required availability can not be achieved within the real- 
istic range of the decision variables, reruns of the simulation with relaxed requirements 
can offer more insight into the problem. In Table 5 on page 22 the most important pa- 
rameter of this kind is shown. 

An example for this feature is any electronic device backed up by a mechanical 
device, where the electronic device may have = 14, whereas for example commu- 
nication devices will generally have = 0 . 



Table 5. VARIABLE REQUIREMENT PARAMETERS 



Parameter 


A'alue (hours) 


Description 


^ T'x maj 


Appropriate 

Value 


Maximum allowable downtime for component "X" 
which will not decrease the operational capability of 
the system, and therefore will not count as a failure 



D. REALIZATION OF THE IDEALIZED APPROACH 

The applicability of the available closed form tools for the modeling and evaluating 
of the behavior of the complex modular structure of a new and mostly unknown elec- 
tronic weapon system within the given three-echelon maintenance system of the German 
Army is limited in three ways; 
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1. It is a nightmare to apply the closed form tools for calculating the desired results 
under the assumption of Weibull- or Gamma-distributed Times Between Failures 

2. Applying exponential failure rates will make the closed form calculations much 
easier, but too many assumptions have to be made, unreasonably simplifying the 
real world environment 

3. Though a closed form calculation could be done by a computer program, this 
program will not be flexible enough for applications with dilTerent configurations. 

The only way to proceed is the application of an open form method, the simulation 
of the complex real world situation. In simulating this situation it is generally assumed 
that 



• A system is down when one component fails, and is up again when this component 
is replaced 

• No aging takes places during downtimes 

• For each repaired component a new time to next failure starts. 

Using simulation we have to decide on the length of the time period simulated. This 
time period will be split up in 

1. the phase used for determination of the reliability of the system (though we will not 
use it as a decision criterion) 

2. a second phase up to the end of the time period, which is determined by war ana- 
lysts to reflect a realistic war scenario (to obtain numerical values for spare part 
stocks at Organizational and Intermediate Maintenance facilities) 

3. a third phase up to the end of simulation time, which has to be determined yet (to 
cover long-run aspects) 

For illustration purposes we will introduce a Sample System in the next chapter (see 
Figure 8 on page 34). From the (fictitious) current AD.M (Acquisition Decision Mem- 
orandum) for this Sample System we learn that the required time period for reliability 
considerations (the average system availability required is 90 %) is set to 175 hours, i.e. 
5 weeks of peacetime or 1 week of wartime. So the length of the first time phase will be 
175 hours. 

Though the future NATO wanime scenario is about to be redefined after the end 
of the cold war, the "historical" value of 30 days of wartime is applied. So the end of the 
second time phase will be at 720 hours, resulting in a phase duration of 720-175 = 545 
hours. 

Special considerations are necessar}' to determine the appropriate total simulation 
time. Due to the fact that many components have a MTBF that is decisively greater than 
720 hours, many of these components will not fail within the first two simulation time 
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phases, and might create the impression that they are not necessarily to be kept in stock. 
Another drawback is the fact that the Mean Time To First Failure (MTTFF) is always 
greater than the Mean Time Between Failures (MTBF), wltich causes the average avail- 
ability and the expected MTBF to be computed with higher values than using a longer 
time period. To give each Subassembly and each Element the "chance to fail" within the 
simulation horizon, the total simulation time period should be chosen at a value some 
10 times as large as the largest MTBF-value of any Subassembly or Element. With this 
method the computed availability of the system also asymptotically approaches the 
steady state value, because the initial MTTFF is dominated by an increasing number of 
MTBF-values used. 

Consequently the time horizon for our Sample System will be 15230 hours (MTBF 
of Subassembly .A02.A = 1523 hours), divided in a first phase of 175 hours (to obtain a 
reliability value), a second phase of 545 hours (to obtain the necessary spare part stocks 
for a war scenario of 30 days), and a third phase with the remaining 14510 hours (to 
achieve the availability and the MTBF-value of the system in the long run). 
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IV. DEVELOPED AND APPLICABLE MULTI-ECHELON MODELS 



A. EVALUATION OF EXISTING MULTI-ECHELON MODELS 

Research among existing multi-echelon simulation models used by all branches of 
the U.S. Armed Forces showed that these programs are mainly aimed at the solution of 
the following problems [Ref 19); 

• Tie budget dollars to readiness. This approach can not help in our case, because 
costs are unknown at the respective point of time in the acquisition process. 

• Determine the inventor}’ levels required at each echelon of supply given a readiness 
objective. This aspect comes closer to the problem to be solved, but it is based upon 
a given number of repair personnel. While this feature can help in the second part 
of the problem, it does not solve the essential problem of determining the number 
of repair personnel at each maintenance echelon. 

• Predict readiness given the inventory level at each echelon of supply. Also this feature 
can not help in our case, because its basis are the numbers we need from the sim- 
ulation. 

Generally it is to be stated that all models concentrate on the supply side of the 
multi-echelon idea. As stated for the given problem in II.C.2.e., necessaiy stock levels 
are only considered as far as these stocks are located at the respective maintenance fa- 
cilities. The three-echelon maintenance system represented by our stochastic model (see 
Figure 6 on page 20) is a closed environment, where the only link to the "outside world" 
is the replacement parts stock for D-Units at Depot .Maintenance. 

One way to proceed is the development of a new program that simulates the be- 
havior of a weapon system with four indenture levels within the military environment 
of a closed three echelon maintenance system. But this task is far beyond the scope of 
a master's thesis. Another way to approach the problem is the application of one of 
these existing simulation programs under flexible use of the offered features close to the 
problem. One simulation program that is both applicable under this approach and 
available for use by a foreign student at the Naval Postgraduate School is the "TIGER 
Reliability Computer Program", developed and distributed for Government use by the 
NAVAL SEA SYSTEMS COMMAND, Washington D.C. [Ref 20). 

B. THE SIMULATION PROGRAM "TIGER" 

TIGER is designed to calculate the mission performance parameters of ship system 
reliability and availability, and concentrates on the efficient supply with spares within 
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the Naval Supply System under consideration of available repair shop capacities and 
failure characteristics of the used equipment. It is in use in the US Army and US Air 
Force, too, and can be applied stepwise to obtain ail the data which are needed to solve 
the given decision problem. 

For use in this thesis, the program is first introduced with the problem relevant input 
and output options. Later the necessary sequence of steps in applying "TIGER" is de- 
veloped using a sample system. 

I. General Overview 

The general objective of "TIGER" is the prediction of RA.M (Reliability, 
Availability, Maintainability) performance of a general system, defined by data about 
the components within its indenture levels. "TIGER" is an event driven stochastic sim- 
ulator [Ref 20, p.2-5), and generates internally the following component events: 

1. Failure of a component 

2. Arrival of a spare part for a waiting component 

3. Release of shop capacity for a waiting component 

4. Repair of a component 

The special features necessary to solve the given problem are listed below [Ref 20, p.2-7 
- 2-9], including first remarks about their sometimes limited applicability for the given 
problem. 

• Gamma distribution for failures and delays, and exponential distribution for repair 
times; however, only integer ^-values from 1 to 9 are possible (where /? = 9 comes 
closest to a Normal distribution) 

• Limited shop capacities; these shop capacities are the central decision parameters; 
however, the only shops considered are one "General Shop" and up to 20 specialty 
shops 

• Allowable downtime; because not all components of-a weapon system are essential 
for the mission performance, the failure of certain components can be tolerated for 
some time without being counted as system failure 

• Group rules; using string rules all grouped components are turned off while the 
group is down due to failure of a specified control component 7, while standby rules 
take care of redundancies 

• Logistic models; offering both spares inventory policy and unlimited spares 



7 In order to avoid excessive simulation run times the application of this rule is only appro- 
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2. The Input Formats 

The input formats are described in [Ref 20, section 3]. To get an idea about the 
input structure, the relevant input formats needed to start a "TIGER" simulation are 
described below (the numbers indicate the respective TIGER input format): 

1. Distinctive name of simulation (for later identification) 

2. Number of Monte Carlo simulations; optional individual integer random seed 

3. Time horizon of simulation; phase definitions for successive simulations under 
changing conditions and/or changing configurations (up to 6 phases in one simu- 
lation run) 

4. - blank - 

5. Selection of printout option 

6. - blank - 

7. Multiplier for all MTBF-values to model special conditions; multiplier for all 
MTTR-values to model special conditions; capacity of general shop; capacity of 
special repair shops 

8. Component identification: user defined type number (between 1 and 200) and name 

for easier identification of maximal 200 difierent component types; MTBF; MTTR 
or indicator for not repairable item; probability that a repair re- 

quires a part at all (complementar\’ probability that a failure can be fixed by simple 
methods); Gamma shape parameter for delay times; Gamma shape parameter for 
failures 

9. - blank - 

10. - blank - 

1 1. - blank - 

12. enumeration of all components used in the System (up to 500 components of the 
above defined 200 different types); a system in the way "TIGER" is used here can 
be a single unit of the Weapon System with components being Subsystems, or can 
be a military command level with components being military units using S„„,, units 
of the Weapon System 

13. - blank - 

14. Indicator for unlimited spares or general number of spares (same number for each 
type of spare) 

15. Individual number of spares per component (overrides format 14) 

16. System definition (system in a general sense, not as an indenture level of an elec- 
tronic system; from now on referenced as "TIGER system definition"); in contrary 
to the known or estimated components which are defined with type numbers 1 to 
500 in format 8, in this and the two following formats the unknown System, the 
Subsystems and the Assembhes are defmed with type numbers 501 to 1000. 
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17. Subsystem definition (components building up System defined in format 16; from 
now on referenced as "TIGER subsystem definition); allowable downtimes for 
these "TIGER subsystems" 

18. Group definition (components building up the "TIGER system" and the "TIGER 
subsystems" defined in format 16 and 17, which are controlled by standby- and 
string rules (see IV.B.l) 

19. Standby- and string rules 

20. - blank - 

21. - blank - 

3. The Output Formats 

"TIGER" offers a variety of output options. The output formats are listed and 
described below as far as they are relevant for the given problem; 

1. Phase Figure of Merit Final Report [Ref 20, p. 10-7] for the entire system 

a. Mean for reliability at the end of each time phase 

b. Mean for availability at the end of each time phase 

2. Final Figure of Merit Summary [Ref 20, p. 10-7] for the entire system 

a. Mean and variance for reliability at the end of the simulation time 

b. Mean and variance for availability at the end of the simulation time 

c. Mean and variance of the MTBF at the end of the simulation time 

d. Estimate of the long-term value of the availability 

e. Estimate of the long-term value of the MTBF 

3. Subsystems Figures of Merit [Ref 20, p. 10-7] for each subsy^stem 

• Average Availability at the end of each time phase 

4. Component Performance Statistics [Ref 20, p. 10-12] 

• Summary' of spares used at the end of the simulation time 

5. Critical Component List [Ref 20, p. 10-12]. 

• Contribution of each component type to the unavailability of the entire system 
and each subsystem 
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V. THE DECISION MODEL 



A. DECISION VARIABLES 

As already discussed in 111.C.2 and shown in Table 4 on page 22, the following de- 
cision variables have to be handled; 

1 . Rj, the number of repair personnel at Maintenance Echelon 2 (Organizational 
Maintenance) 

2- /’ 2 „„*(B-Unit), the number of spare B-L'nits in stock at Maintenance Echelon 2 

3. R 30 , the number of repair personnel at Maintenance Echelon 3 (Intermediate 
Maintenance) at Division level 

4. P 3 J),„^*(B-,C- or D-Unit), the number of spare B-, C- and D-Units in stock at 
Maintenance Echelon 3 at Division level 

5. R 3 C, the number of repair personnel at Maintenance Echelon 3 (Intermediate 
Maintenance) at Corps level 

6 - P 3 c,r„A(B-,C- or D-Unit), the number of spare B-, C- and D-Units in stock at 
Maintenance Echelon 3 at Corps level 

However, the way to obtain R 30 and Rio„cci, the same as obtaining R^c and Ricuock 
- they differ only in the number of weapon systems to be supported by one Maintenance 
Batallion. So in the further approach, which will develop the actual utilization of avail- 
able tools, we will cover only R^, R^, P 2 ,„,,*(B-Units) and /’ 3 ,„,:*(B-, C- and D-Units). 

B. INFLUENCE DIAGRAM 

Due to the fact that there is no directly applicable simulation model for the given 
maintenance environment, we have to decide about the necessaiy steps in using the 
available programs. To gain insight into the decision problem structure, we develop an 
Influence Diagram , shown in Figure 7 on page 30. 

1. Given Data 

The only given data at the beginning of the decision process are 

• The (rough) structure of the new Weapon System with 
• definition of functional units 

■ level of used technology 

■ redundancy concept 

• The required Average System Availability 
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2. Available Data 

For many already deployed systems the TBF- and TTR-values for Subsystems, 
Assemblies, Subassemblies and Elements are recorded and available. The functional 
characteristics of these evaluated components are known, also their technology level. 
Based on the given System Structure we can exploit similarities between components of 
the future system and known components. However, this link is not straightforward, and 
has the character of an assumption. 

3. Direct Conclusions 

Based on the used TTR- and TBF-values for the Subassemblies and Elements 
of the new system, and assuming unlimited personnel and materiel resources at Organ- 
izational Maintenance, we can obtain an Upper Availability Limit for one unit of the 
new system. This is a technology determined upper value, which can not be increased 
by any organizational decision or any other means. 

4. Decision Variables 

a. Personnel in Organizational Maintenance 

Based on the System Structure, the required Average System Availability, 
the estimated TBF-values and the Upper Availability Limit, and under assumption of 
unlimited supply of B-Units at Organizational Maintenance, the consequences of certain 
numbers of repair personnel at Organizational Maintenance can be modeled and a de- 
cision based on an analysis can be made. 

b. Materiel in Organizational Maintenance 

Based on the available personnel at Organizational Maintenance (= the 
number decided upon), the estimated TBF-values and the underlying war scenario, the 
consequences of certain stock levels of B-Units at Organizational Maintenance can be 
modeled and a decision based on analysis can be made. 

c. Personnel in Intermediate Maintenance 

Based on the System Structure, the estimated TBF-values and the Upper 
Availability Limit, and under assumption of unlimited supply of C- and D-Units at 
Intermediate Maintenance, the consequences of certain numbers of repair personnel at 
Intermediate .Maintenance can be modeled and a decision based on an analysis can be 
made. 

d. Materiel in Intermediate Maintenance 

Based on the available personnel at Intermediate Maintenance (= the 
number decided upon), the estimated TBF-values and the underlying war scenario, the 
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consequences of certain slock levels ofB-, C- and D-Units at Intermediate Maintenance 
can be modeled and a decision based on analysis can be made. 

5. Final Conclusion 

Based on the personnel and materiel quantities at Organizational Maintenance, 
and under assumption of sufficient personnel and materiel quantities at Intermediate 
Maintenance ( = the numbers decided upon), the Maximum Achievable Average System 
Availability under the quantified Maintenance System can be checked versus the Upper 
Availability Limit. 
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VI. SIMULATION WITH THE TIGER PROGRAM 



At first the preparative structuring of the new Weapon System for the input process 
is described, followed by the essential input steps for each successive simulation run. The 
applicability of the respective results for our decision problem is shown, and the rea- 
soning for the next input step is derived. 

A. PREPARATIVE STRUCTURING OF THE WEAPON SYSTEM 

To simplify the illustration of the use of "TIGER" in solving the given problem, and 
to show the emerging results and their consequences, the program is applied to the 
simple yet complete Sample System configuration shown in Figure 8 on page 34. 

In contrast to the "TIGER" concept only ver>' few components (if any at all) shown 
in our Sample System configuration have known TBF and TTR. Proceeding down from 
the System level, and skipping the Subsystem level, all Assemblies are checked for avail- 
able MTBF-data, /?-values for the distribution of the TBF and MTTR-data: 

1. If there are no real data available for an Assembly, we proceed further down and 
check the Subassemblies and those Elements which are not a direct part of a Sub- 
assembly. Elements within a Subassembly are only handled by depot level mainte- 
nance, which is not covered here (see I.D.3) 

a. If we have real data for a Subassembly or an Element, which might be in use in 
an already deployed weapon system, these data are applied 

b. If there are no real data available, data from a component with similar functional 
characteristics and a comparable level of technology are applied 

c. In case of several similar components with different parameters or in case of 
components with a totally new conceptual design, the best possible estimates 8 
have to be applied 

2. If we have real data from an Assembly, which is in use in an already deployed 
weapon system, the Assembly itself is treated as an unknown, but with exactly one 
known Subassembly 

3. As a further preparation for the input the known or estimated Subassemblies and 
Elements are assigned a type number between 1 and 500, all unknown Subsystems 
and Assemblies a number between 501 and 1000. One possible choice for assigning 
these numbers is shown in Figure 8 on page 34. 

At the end of this process each branch of the configuration tree ends with a com- 
ponent for which the MTBF, p and MTTR data are fixed. Because we do not have any 



8 Again, the user has to be experienced in his functional specialty 
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Subassemblies (XXXA etc.) and Elements (XXX01 etc.) I C03A Ij.1 



11 


MTBF = 1327,6 = 3 
A01A MTTR = 4.1 


13 


MTBF = 841, 6 = 9 
A02A MTTR = 3.6 


15 


MTBF = 344, 6 = 9 
A03 MTTR = 1.5 


12 


MTBF = 644, 6 = 9 
A01B MTTR = 3 9 


14 


MTBF = 1523,6 = 9 
A0201 no repair 




known assembly 



2 reduncJant 
assemblies 



21 

( 22 ) 

23 

(24) 



MTBF = 225, 6 = 1 


25 


MTBF = 866, 6 = 7 


80101 no repair 




B0201 no repair 


MTBF = 534, 6 = 9 
B0102 no repair 


26 


MTBF = 1167, 6 = 5 
B02A MTTR = 13 8 
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MTBF = 544, 6 = 9 
C0101 no repair 


33 


MTBF = 1322, 6 = 9 
C02A MTTR = 3.8 


32 


MTBF = 732, 6 = 7 
C0102 no repair 


34 


MTBF= 1003,6 = 4 
C02B MTTR = 9.5 










41 


MTBF = 375, 6 = 5 
D01A MTTR = 1.5 


44 


MTBF = 554, 6 = 5 
D02A MTTR = 7.2 


42 


MTBF = 445, 6 = 9 
D01B MTTR=4 1 


45 


MTBF = 1303, 6 = 3 
D0201 no repair 


43 


MTBF= 1127,6 = 8 
D01C MTTR = 22.6 
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(36) 

(37) 



MTBF = 210,6 = 9 
C03A MTTR = 8 4 



3 redundant 
subassemblies 
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MTBF = 628, 6 = 2 
D03 MTTR = 2.3 



known assembly 



Figure 8. Sample System Configuration (Prepared for Input) 
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information about interdependencies between components at this stage of the develop- 
ment process, we assume that there are none at the moment. Components with stand-by 
redundancies (groups of components, where in case of failure of the active component 
another component starts operating) are grouped using the TIGER stand-by rule; gen- 
erally string rules will not be applied, because for electronic equipment with high reli- 
abilities and short repair times the MTBF, MTTR-quotient (see footnote 7 on page 26) 
will mostly be considerably higher than 50. 

B. MAXIMUM AVERAGE WEAPON SYSTEM AVAILABILITY 

The input file for the first simulation step lists all Subassemblies and Elements with 
their (known or estimated) individual MTBF- and ^-values to determine the failure 
characteristics of the entire (unknown) system. Each failure of any component initializes 
the repair of the failed A-L'nit (Subsystem) by replacing the failed B-L'nit (Assembly 
within the failed A-Unit). This repair time can be assumed to be relatively constant due 
to the technology used (BITE etc., see Table 1 and Table 3, MARTy^). Starting with the 
general maintenance system, i.e. without applying any exceptional regulations, we will 
obtain the maximum achievable availability under ideal conditions by assuming both 
unlimited shop capacity and unlimited supply of spare B-Units at Organizational Main- 
tenance. Because, at this point of time, w’e do not need any information about spare 
parts used, we do not need to record the results of the second time phase (see III.D.). 

To gain more insight into the .Maintenance of the new Weapon System, w'e addi- 
tionally consider 2 methods for increasing the numerical value of the maximum possible 
average system availability: 

• RelaAed Tactical Requirements. The Mission Need Statements (MNS), which ini- 
tialize the acquisition process for a new w-eapon system, tend to require an avail- 
ability of a weapon system close to 100% with no allowable downtimes for any 
Subsystem. In many projects this goal can not be achieved even under the ideal 
approach described above. Therefore allowable dow'ntimes for selected Subsystems 
are additionally entered. It is essential to point out, that the quality of the weapon 
system is not improved at all by this means - it is just a statistical improvement aimed 
at the purpose of the decision aid ! 

• Exceptional Spare Stock of A-Units (Subsystems) at location of Organizational 
Maintenance. Now an unlimited spare stock of A-Units at the organizational level 
is allow'ed, actually reducing the mean delay time until resuming operation. 

1. Step 1, Run 1 - System in the General Maintenance System 

For the first step one unit of the Weapon System is defined in a format 16 
statement ("TIGER system definition"), and all Assemblies, Subassemblies and Elements 
are assigned to their respective Subsystem under format 17 ("TIGER subsystem defi- 
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nition"). Strictly following the rules (see Il.D.l. - no spare stock of A-L'nits at the or- 
ganizational level), the resulting mean delay time until resuming operation is 
MART^ + LDTsuck + ADT 2 = 5, given the required B-L’nit is available at the re- 
placement parts stock of the Organizational Maintenance. Due to the "fixed" repair time 
of 5 hours this value is entered as "real organizational delay", while the MTTR-values 
for all Subassemblies and Elements are set to 0.001 (Tiger default value). This method 
is necessarx' to neglect any repair times for these components, which are irrelevant in this 
first step. Without regarding any eventually allowable downtimes, the results of the first 
simulation run offer a set of data based on the technology used and on the unmodified 
general maintenance system. Any possible real-world logistic delays could not happen 
due to assumption. 

The following results are determined from the first run: 

• Upper limit for Average System Availability under consideration of technology and 
general maintenance system. Without any exceptional regulations within the general 
maintenance system no higher value for the average availability can be achieved. 

• MTBF for one unit of the System under the conditions stated above 

• As additional information we obtain the Reliability for the time period entered as 
first phase duration. But as pointed out above (see 111.B.4.), reliability can not be 
used as a criterion for the upcoming decision, and therefore will be tracked only 
occasionally. 

The relevant results for our Sample System (for this and the next three runs) are 
listed in Table 6 on page 38. 

2. Step 1, Run 2 - System under Relaxed Tactical Requirements 

In many projects the desired availability can not be achieved even under the 
ideal approach modeled in Run 1. Therefore the second run additionally regards allow- 
able downtimes for selected Subsystems under tactical considerations. 

The results of the second run offer: 

• Tactically Increased Upper Limit for Average System Availability . By allowing 
downtimes for not-operationally-essential Subsystems, the technology determined 
upper limit for the average availability of each unit of the Weapon System will be 
increased once more, offering insight into the consequences of tight requirements. 

• MTBF for one unit of the System under the conditions stated above 

The MTBF-value should be decisively higher than that in Run 1 (less failures 
counted for calculation of down time). 
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3. Step 1, Run 3 - System in Modified Maintenance System 

For the third run one unit of the Weapon System is defined in the same way as 
in Step 1. But now an unlimited spare stock of A-Units at the organizational level is al- 
lowed, reducing the mean delay time until resuming operation to 

+ ADT 2 = 3. This value is now entered as "real organizational delay", while 
the MTTR-values are kept at 0.001. Assuming unlimited shop capacity and no allowable 
downtimes again, an ideal (modified) logistic environment is modeled - the results of the 
third run offer a set of data based on the technology used and represent the maximum 
achievable average availability of the planned Weapon System in the three echelon 
maintenance system under exceptional regulations. 

The following results are offered from the third run; 

• Technology determined absolute upper limit for Average System Availability. With 
no organizational or any other means can any higher value for the average avail- 
ability be achieved within the given maintenance system. 

• MTBF for one unit of the System under the conditions stated above (should be close 
to the MTBF-value obtained from Step 1, Run 1 - differences due to simulation) 

4. Step I, Run 4 - System Behavior under Both Methods 

As described for Step 1, Run 2, additionally allowable downtimes for selected 
Subsystems under tactical considerations are entered. The results of the fourth run offer: 

• Tactically increased absolute upper limit for Average System Availability 

• MTBF for one unit of the System under the conditions stated above (should be close 
to the MTBF-value obtained from Step 1, Run 2 - differences due to simulation) 

5. Evaluation of Step 1 

The requirements and the relevant results from Step 1 for the given Sample 
System are summarized in Table 6 on page 38. 

The standard deviation for all A -values obtained by simulation is 0.000, point- 
ing out that at t= 15230 we obviously have reached a steady state. Dependent on the 
required availability and the results, some options for the further approach might no 
longer be reasonable. In our example, no stock of A-Units at the location of the Or- 
ganizational Maintenance has to be considered, because the required availability of 90 
% can be achieved under the allowable-downtime approach^. 

9 These results also offer insight into the consequences of too tight tactical requirements, which 
might drive up costs if accepted without analysis 
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Table 6. MAXIMUM ACHIEVABLE SYSTEM AVAILABILITY 





Average 

Availability 


MTBF 


R 


mttff 


Requirement 


A = 0.900 








No stock of A-Units, no allowable 
downtimes 


A = 0.892 


43.6 


0.696 


227.2 


No stock of A-Units, relaxed require- 
ments 


A = 0.934 


72.3 


0.924 


299.2 


Unlimited stock, no allowable down- 
times 


A = 0.934 


43.8 


0.700 


214.0 


Unlimited stock, relaxed requirements 


A = 0.960 


72.6 


0.928 


292.3 



So the further approach uses the environment modeled in Run 2. The input file 
for Run 2 is shown completely in Appendix A, and the resulting output for Step 1, Run 
2 is shown partially (without computer system messages, input echo and an error mes- 
sageiO) in Appendix B. 

C. PERSONNEL QUANTITIES AT ORGANIZATIONAL MAINTENANCE 

Still under the assumption of an unlimited stock of B-Units, the unlimited repair 
capacity at Organizational Maintenance will be reduced now to realistic values. To 
model this situation, a new approach is needed, using MTBF-values of all Subsystems, 
and regarding the entire militaiy user unit. We do not need information about spare 
parts used nor about the reliability of the subsystems. Therefore we do not record the 
results of the first two time phases. 

1. Step 2, Run 1 - MTBF- Values for Subsystems 

To obtain these MTBF-values, each Subsystem is defined in a format 16 state- 
ment ("TIGER system defmition") and as only Subsystem under format 17 ("TIGER 
subsystem definition"), while all its Subassemblies and Elements are assigned to this one 
Subsystem. The environment for these simulation steps assumes no stock of A-Units at 
Organizational Maintenance, and no allowable downtimes are entered to obtain the 
technology determined MTBF. The repair shop capacity is without influence on the re- 

10 TIGER calculates the reliability for t= 15230 as /? < 16"“ and causes a "Floating Point 
Underflow Exception"; using "Standard Corrective Action", the value of R is set to 0.000, and the 
program completes correctly 
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suit of Run 1, and is kept unlimited. One run for each Subsystem has to be performed. 
The following result is offered from the first run; 

• Technology determined MTBF- Values of all Subsystems 

Due to the characteristics of the TIGER simulation these values are offered 
without any distribution parameters. In order to avoid unrealistic simplification by using 
the mean values only, the generally accepted assumption of exponential distribution for 
time between failure (see III.A.l) will be used for further computations. 

For our Sample System the following results are obtained: 



Table 7. MTBF- VALUES FOR SUBSYSTEMS 



Subsystem 


MTBF 


^ s^mvlcticrt 


A 


A 


145.7 


6.513 


0.966 


B 


471.3 


6.470 


0.990 


C 


206.0 


7.035 


0.976 


D 


110.3 


6.073 


0.956 


Entire System 


72.30 


6.150 


0.934 



2. Step 2, Run 2 - Minimum Personnel Quantity, Unlimited Stock 

Starting with personnel quantity of 1 (the minimum value - see II.D.l), we de- 
fine the military unit in format 16 ("TIGER system definition"), consisting of sets 
of all Subsystems. For our Sample System we learn from the (assumed) ADM that each 
militaiy^ unit has S„„„ = 17 units of the Weapon System. The MTTR is 2 hours (see 
Table 3); the stock of B-Units is unlimited; the delay time is + ADT 2 = 3 

hours. Due to the characteristics of TIGER the "allowable downtime" approach is not 
applicable in this data input configuration - allowable downtimes can be entered only for 
"TIGER subsystems" (here the 17 weapon systems). That means for our Sample System 
that the maximum achievable Average System Availability will be 0.892 (subject to de- 
viations due to simulation) instead of 0.934, which has to be considered in evaluating the 
output and deciding upon the personnel quantity. 

Because we are primarily not interested in the "TIGER system" availability (the 
"availability" of one militar>' unit), but in the availability of each unit of the Weapon 
System (the "TIGER subsystem" availability), the output option for subsystems has to 
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be chosen. Nevertheless, defining the militar>’ unit as available (combat ready) if 15 out 
of 17 weapon systems are up, we will have a glance at this value. 

The following result is offered from the second Run: 

• Upper limit for Average System Availability at minimum personnel quantity at Or- 
ganizational Maintenance 

3. Step 2, Run 3 - Increased Personnel Quantity, Unlimited Stock 

If the resulting upper limit for the Average System Availability is insufficient, 
further runs with incremented personnel quantities (up to a realistic limit) have to be 
performed, eventually resulting in the 

• Upper limit for Average System Availability for personnel quantity of 2 at Organiza- 
tional Maintenance 

• Upper limit for Average System Availability for personnel quantity of 3 at Organiza- 
tional Maintenance 

• ... 

• Upper limit for Average System Availability at maximum personnel quantity at Or- 
ganizational Maintenance. For our Sample System the maximum realistic personnel 
quantity is assumed to be 4. 

For our Sample System the resulting upper limits for the Average System 
Availability for one unit of the Weapon System with a given personnel quantity and an 
unlimited stock of B-Units at the location of the Organizational Maintenance are shown 
in Table 8. 



Table 8. PERSONNEL AT ORGANIZATIONAL MAINTENANCE 



Quantity of Per- 
sonnel 


Maximum Average System Avail- 
ability 


Availability of the Mili- 
tar>' Unit 


1 ( = minimum) 


/i = 0.813, <7 = 0.0006 


0.453 


2 


p = 0.888, a = 0.0005 


0.706 


3 


p - 0.893, <7 = 0.0004 


0.731 


4 ( = maximum) 


p = 0.894, a = 0.0005 


0.731 


Threshold 


0.892 


... 
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4. Evaluation of Step 2 

As a general rule the smallest value for the personnel quantity, which provides 
the desired numerical availability valuell, will be used for all further computations. 
However, the data base used for these calculations is not exact at all - most values are 
(and will be in later applications) very rough estimates. So it is the responsibility of the 
experienced user, to decide about the appropriate personnel quantity. In our case quan- 
tity 1 provides an Average System Availability of 0.813 versus the maximum availability 
of 0.892 (equivalent to 91.1 %), quantity 2 provides 0.888 (equivalent to 99.6 %), and 
quantity 3 even offers 0.893, which can be considered as being the maximum value 
(again, deviations caused by simulation). For our Sample System, quantity 2 will be used 
further on. 

If even the realistic maximum number of repair personnel is insufficient to 
achieve the desired numerical availability, the introduction of an exceptional stock of 
A-Units at Organizational Maintenance might be regarded by repeating Step 2 not based 
on Step 1, Run 2, but on Step 1, Run 3 or 4. 

If under the assumption of an unlimited stock of B-Units a certain personnel 
quantity is sufficient, this quantity can be looked upon as the maximum quantity nec- 
essary. But this personnel can not utilize an unlimited stock. Consequently the unlimited 
stock of B-Units at Organizational Maintenance should now be reduced to realistic val- 
ues, applying the personnel quantity obtained in Step 2. 

D. MATERIEL QUANTITIES AT ORGANIZATIONAL MAINTENANCE 

As pointed out in lI.C.2.e., stock levels wiW only be considered as far as they are 
located at the facilities of the respective .Maintenance Echelon. So now we need to know 
how many units of each B-Unit should be held at each location of Organizational 
.Maintenance. The main reason for keeping this stock at all is the chance to increase the 
Achievable Average System Availability during combat. The second time phase (as de- 
fined in III.D.) becomes relevant now, and due to the output characteristics of TIGER 
(summary' of spares used at the end of the simulation time - see IV.B.3.4) the simulation 
time horizon is now reduced to 720 hours. 



1 1 See the discussion about the application of the "allowable downtimes" idea for this simu- 
lation step in VI.C.2. 
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1. Step 3, Run 1 - Maximum Number of Spare Parts Used in War Scenario 

Applying the personnel quantity obtained by Step 2, Run 2 or 3, we simply re- 
peat the respective simulation run with decreased time horizon. The "unlimited spares" 
option is kept in the input file to prevent any supply from outside. The result of this 
repeated run will be the 

• Upper Limit for Spare Parts needed at Organizational Maintenance in the Applied 
War Scenario 

If every failure results in the replacement of the respective B-Unit by personnel 
of Organizational Maintenance, this is the maximum number of spare parts needed 
during the war scenario. By setting the "spares allowance" for each Assembly individ- 
ually to the smallest integer being greater than the computed values, while still assuming 
unlimited supply at the intermediate level DES, we will obtain from Step 3, Run 1 the 
Maximum Average System Availability achievable with this stock level. Because some 
parts will now be used out of the Intermediate Maintenance DES - some simulation runs 
need more than the average number of spare parts - we additionally enter 
LZ)Td £5 = 10 hours, the delay time to obtain spare parts from the DES. 

2. Step 3, Run 2 - Consequences of Lower Allowances 

With the above values being upper limits, we want to analyze the consequences 
of lower allowances now. The only drawback of lower stock levels is the increased lo- 
gistic delay time due to supply out of the DES of the respective Maintenance Batallion. 
Instead of checking each combination of decreased allowances, we set all allowances at 
Organizational Maintenance to Zero, and keep the stock level at the Intermediate 
Maintenance DES unlimited, thus obtaining the 

• Upper Limit for Spare Parts needed at the Intermediate Maintenance DES in the 
Applied War Scenario 

• Upper Limit for the Achievable Average System Availability with Zero Stock Allow- 
ance at Organizational Maintenance 

3. Step 3, Run 3 - Consequences of Zero Stock Allowances 

In economically tough times even the necessity of any stock levels outside the 
militar>' supply line might be in doubt. To be able to present data for this situation, we 
finally set both the stock level at Organizational Maintenance and at the Intermediate 
.Maintenance DES to Zero (setting the DES to Zero with stock of Organizational 
Maintenance at upper limit will not change the results from Run 1, because only an 
average of 3 or 4 Assemblies will be used from the DES). Repeating Run 2, but replacing 
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the 10 hour delay (for receiving the needed Assembly from the respective DES) by a 35 

hours delay (for the use of the militarv’ supply line), we obtain 

• Upper Limit for the Achievable Average System Availability with Zero Stock Allow- 
ance 

The results of Step 3, Run 1 to 3 are summarized in Table 9. 



Table 9. MATERIAL AT ORGANIZATIONAL MAINTENANCE 



.Modeled 
Stock Lev- 
els(0 = 
Org Maint, 
I = Interm 
Maint) 


Allowance at 
OrgMaint 
(Assembly 
A/B/C/D) 


Allowance 

at 

IntermMaint 
DES (As- 
semblv 
A/B/C/D) 


Maximum 

Average 

System 

Availabil- 

ity 


B-Units 
obtained 
from Inter- 
mediate 
Mainte- 
nance DES 
(Assembly 
A/B/C/D) 


B-Units 
obtained 
from Sup- 
ply line 
(Assembly 
A/B/C/D) 


Upper 
Limit at O, 
unlimited 
DES at 1 


101/32/73/134 


unlimited 


0.885 


4/3/3/3 


O/O/O/O 


Zero at O, 
unlimited 
DES at I 


0/0, 0'O 


unlimited 


0.765 


97/32/70/125 


O/O/O/O 


Zero at 0, 
Zero DES 
at 1. unlim- 
ited supply 


0;0/0/0 


0'0,0/0 


0.477 


O/O/O/O 


84/30/63/104 


Threshold 


- 


- 


0.88S 


- 


- 



4. Evaluation of Step 3 

All calculations in Step 3 have been performed under the assumption that 
available stocks are not refilled during the time period set by the applied war scenario. 
Nevertheless unlimited supply of spare parts at the respective source was used in the 
simulation runs. While this method was used in Run 1 and 2 just as a tool to obtain the 
maximum stock levels at Organizational Maintenance and the Intermediate Mainte- 
nance DES, the use of the unlimited supply line (see assumption stated in lI.C.2.e.) was 
realized in Run 3 and 4 to model the situation of Zero allowances. 

Evaluating the data displayed in Table 9, consequences of cuts proposed in 
budgetary discussions can be demonstrated based on analysis rather than on pure and 
not necessarily wrong, but improvable intuition. Pertaining to numerical numbers for 



43 



optimal stock levels at Organizational Maintenance and Intermediate Maintenance DES, 
we need more information about the back flow of repaired components, which are used 
to refill both the stock at Organizational Maintenance and the DES at Intermediate 
Maintenance during the simulated time period. 

E. QUANTITIES AT INTERMEDIATE MAINTENANCE 

Entering the intermediate level, the environment is similar to that modeled for the 
organizational level; however, the objects for repair are now Assemblies (B-Units). These 
B-Units fail as described above, are replaced by the Organizational Maintenance, and 
finally arrive some time after failure at the Intermediate Maintenance. TIGER does not 
offer any links between Organizational and Intermediate Maintenance; so we can not 
simulate the exact arrival times. But we can model this delay time by modeling the ar- 
rival at Intermediate Maintenance at the time of failure, and covering the delay time by 
ADTi + LZ) 7j„j*(Organiz.) -I- LZ) r 5 „j*(Intermed.) -f ADT^ = 39, the number of hours 
caused by administrative and logistic delay per repair job in Maintenance Echelon 3 (see 
Table 3 on page 21) plus the delay time occurred in Organizational .Maintenance while 
replacing the defective B-Unit. Under the assumption of an unlimited stock of C- and 
D-Units, we first have to obtain the MTBF-values of all Assemblies, and then have to 
model all subordinate militaiy units served by the Maintenance Batallion. For our 
Sample System we learn from the (fictitious) AD.M, that each Corps will have three Di- 
visions using the new Weapon System, and that each Division will have 3 Brigades, each 
commanding 2 Militaiy Units supplied with 17 Weapon Systems each. Referring to 
Table 2 on page 12, each Maintenance Batallion at the Division level will service 102 
Units of the Weapon Systems. 

1. Step 4, Run 1 - MTBF-Values for Assemblies 

To obtain these .MTBF-values, each Assembly is defmed in a format 16 state- 
ment ("TIGER system definition") and as only component under format 17 ("TIGER 
subsystem definition"), while all its Subassemblies and Elements are assigned to this one 
Assembly. No downtimes are applied, and any repair shop capacity is kept unlimited. 
One run for each Assembly has to be performed. The following result is offered from the 
first run: 

• Technology determined MTBF- Values of all Assemblies 

As discussed in Vl.C.l., the generally accepted assumption of exponential dis- 
tribution for time between failure will be used for further computations. 

The results for our Sample System are shown in Table 10 on page 45. 
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Table 10. MTBF- VALUES FOR ASSEMBLIES 



Assembly 


MTBF 


^ stmuiatiori 


A 


Assembly .AOl 


455.6 


8.357 


0.989 


Assembly A02 


56 j .4 


8.669 


0.991 


Assembly A03 


S44.0 


MTBF is given 


0.986 


Subsystem A 


145.7 


6.513 


0.966 


Assembly BOl 


161.4 


7.429 


0.970 (2 redundant 
Assemblies in 
Subsystem)) 


Assembly B02 


511.0 


8.749 


0.990 


Subsystem B 


471. S 


6.470 


0.990 


Assembly COl 


S21.1 


8.088 


0.985 


.Assembly C02 


5S7.0 


8.672 


0.991 


Assembly COS 


S807500 


0.000 


1.000 (3 redundant 
subassemblies) 


Subsystem C 


206.0 


7.035 


0.976 


.Assembly DOl 


175.6 


6.689 


0.972 


.Assembly D02 


56S.7 


8.995 


0.991 


.Assembly DOS 


62S.0 


.MTBF is given 


0.992 


Subsystem D 


. IIO.S 


6.073 


0.956 


Entire System 


72.30 


6.150 


0.934 



2. Step 4. Run 2 - Minimum Personnel Quantity, Unlimited Stock 
a. Approach as Proved in Step 2 

So far the new Weapon System could be treated without regarding different 
fields of technology. MTBF-values are computationally independent from the used 
technology, and the personnel at Organizational Maintenance could be planned across 
the fields of technology due to the way they are supposed to perform: localize defective 
LRU by using BITE or straightforward traditional techniques, and replace them. At 
Intermediate Maintenance however, personnel for all different fields of technology have 
to be available. To show the modeling of this situation, we assume that our new Weapon 
System is made up of four different fields of technology, resulting in the use of 4 "TI- 
GER specialty shops". 
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We start with personnel quantity of 2 (the minimum value - see ll.C.2.b.), 
defining the Division in format 16 ("TIGER system definition"), consisting of sets 

of the number of Assemblies used per System. Each Assembly is defined by its Subas- 
semblies and Elements, and the MTTR for each Assembly is determined by the used 
technology (see 111.B.2. and Table 3 on page 21). The stock of C- and D-Units is as- 
sumed to be unlimited. 

For our Sample System T'o = 102, resulting in 1224 "TIGER subsys- 
tems"; the (assumed) MTTR for the different technologies are 7 (Subsystem A), 4 (Sub- 
system B), 12 (Subsystem C) and 3 (Subsystem D). The delay time is 39 hours. 
b. Dimensional Problems 

At this point we are about to run into dimensional trouble with TIGER. 
Table 11 compares the dimensional needs to perform Step 2, Run 2 (Personnel at Or- 
ganizational Maintenance) and Step 4, Run 2 (Personnel at Intermediate Maintenance) 
with the capacity of TIGER. 



Table II. DIMENSIONAL PROBLEMS WITH "TIGER" 



Data 


Capacity 
needed 
(Step 2) 


Capacity 
needed 
(Step 4) 


Capacity 

offered 


Number of distinct Subsystems 


17 


1224 


31 


Number of Component types 


20 


20 


200 


Number of distinct Components 


68 


2040 


500 



First of all, I want to emphasize that this is not the fault of the TIGER pro- 
gram !. As pointed out in IV.A., Tiger is one of the available simulation programs, and 
in this application it has not been used in the way it w'as designed. It is moreover a sign 
of the versatility of TIGER that it could be used so far in such a successful way. But 
w'e will run into trouble even earlier, if we want to model electronic material of the 
combat troops. As discussed in ll.C.l., combat units have a large number of identical 
equipment. If we tr>', for example, to obtain data for the maintenance concept for the 
electronic components of a battle tank - in general an. Armored Batallion has 52 battle 
tanks (52 TIGER subsystems in Step 2 versus the capacity of 31 subsystems) -, we can 
not use the described approach. 
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c. Coal to be achieved by Intermediate Maintenance 

Another problem arises in defining the optimality criterion for Step 4, Run 
2. In Step 2 the goal to be achieved was clearly defined: keep the Average System 
Availability at or above the numerical value required by the ADM ! We could use this 
criterion if TIGER would offer the feature of refilling any stocks with components re- 
paired within the Maintenance System. Due to the origin of TIGER in the Navw, the 
general shop (and eventually involved special shops) repair the Weapon System as a 
whole under the environment of a Three Echelon Supply System. There is no repair of 
defective components performed to refill stock levels - TIGER does not model a Three 
Echelon Maintenance System ! 

Though even if we would be able to handle the dimensional problem, this 
missing link will make it impossible to proceed further on with the use of TIGER. 
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VII. FURTHER APPROACH USING MODSIM 



Being unable to complete our decision aid with TIGER, we now attack the problem 
with the same approach, but applying the simulation language MODSIM II, which 
came to my knowledge only in the last Quarter at NPS. As far as this Thesis is con- 
cerned, only initial feasibility checks are performed. The development of a complete 
simulation program has to be done by follow-on research. 

A. REDUCED STOCHASTIC MODEL 

Applying the TIGER simulation program (see VI.), we have realized that all data 
necessary to solve the given problem can be obtained without modeling the entire 
stochastic model shown in Figure 6 on page 20. Thus we wdll use a reduced stochastic 
model for the remaining parts of the problem (shown in Figure 9 on page 49). 

The only parts of the initial stochastic model to be considered are: 

1. Structured Weapon System with its 

a. Subsystems 

b. Assemblies 

c. Subassemblies 

d. Elements 

2. Organizational .Maintenance with its 

a. Waiting Queue 

b. Repair Capacity 

c. Stock of B-Units for replacement 

3. Intermediate .Maintenance with its 

a. Waiting Queue 

b. Repair Capacity 

c. Direct Exchange Stock 

d. Stock of C- and D-Units for replacement (assumably unlimited ) 

The sequence of steps will be the same as with TIGER, as this approach has been 
proved to be adequate and successful. Upon final development of the problem specific 
.MODSl.M simulation program, the results for our Sample System obtained by TIGER 
can be cross checked with the values obtained by MODSIM. 
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Figure 9. Reduced Stochastic Model 
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B. MODSIM II - GENERAL OVERVIEW 

MODSIM-II is a general-purpose, procedural programming language [Ref. 21]. It 
is an object-oriented language, and it performs discrete-event simulation. Like in real 
world, each object has 

• Attributes (fields with information about the object like MTBF for a component, 
number of repair men for a maintenance facility, or allowances for stocks) 

• Behaviors (methods the object can perform like failing of a component, starting a 
repair by a repairman, or the fact that a stock is decreased by taking out a com- 
ponent). 

Fields within an object can only be changed by a method of this object. Methods 
can be 

• ASK methods, where the object is asked by another object to perform a procedure, 
and where the other object waits until this procedure is finished in order to get 
certain field values back. However, no simulation time elapses during the waiting 
period. 

• TELL methods, where the object is told by another object to invoke a procedure, 
which is performed independently from the "telling" object. No waiting and no re- 
turning of values takes place. 

Each TELL-method can 

• Elapse simulation time during performance 

• Wait for start of performance until being told or until a fixed point in (simulation) 
time 

• Send messages (ASK TELL) to other objects during and after completion. 

Objects can be created dynamically. Fields and methods of objects can be inherited 
to other objects, or can be kept private. .Many objects with the same behavior can be 
used, distinguished by name only (e.g. in our sample system 306 Subsystems of type A, 
306 Subsystems of type B etc.)., but also objects with unique behavior (e.g. the one Di- 
rect Exchange Stock at Intermediate Maintenance). Some built-in objects and built-in 
procedures (used as a built-in method if encapsulated in an object) can be utilized (see 
[Ref 21], Appendices D and E). Table 12 on page 51 gives an overview about the ob- 
jects necessary’ to model our reduced stochastic model, and indicates the dimensional 
ranges for each object pertaining to our Sample System. 
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Table 12. NECESSARY MODSIM OBJECTS 



Name(s) 


Description 


Number necessary 
for the introduced 
Sample System 


Built-in 


CompXXXX 


Component-Object, defining the 
properties of each Subassembly, 
Assembly and Subsystem. 


102 X (12 + 4) = 
1632 


No 


ElemXXXX 


Element-Object, defining the 
properties of each Element 


102 X 20 = 2040 


No 


SvstemXXX 


System-Object, defining the 
properties of each unit of the 
Weapon System 


102 


No 


MaintXX 


.Maintenance-Object, defining a 
maintenance facility 


17 + 1 = 18 


No 


QueueXX 


Queue-Object, defining a "Wait- 
ing for Nlaintenance"-queue 
(FIFO) at a maintenance facility 


17 + 1 = 18 


QueueObj 


RepairXX 


Repair-Object defining the repair 
capacity of one repair person at 
a maintenance facility 


17x(l'2,'3;4) + 
(2,3/4;...) = 
(17/.../68) + (2/...) 


No 


StockXX 


Stock-object, defining stock levels 
at a maintenance facility 


(17 X 12) + 12 = 

216 


Not with 
the fea- 
tures re- 
quired 



C. DEVELOPMENT OF MODSIM-II MODULES 

MODSLM-II programs can be divided into difTerent "modules", each stored in a 
separate file. Each module can be compiled separately, saving both time and resources 
when minor changes have to be made. While the main program (acting like the super- 
visor of the simulation) is stored in one module called .MAIN .MODULE, many com- 
monly used variables and types can be stored in one or several DEFDTTION 
.MODULES. Commonly used procedures additionally need to be coded in an accompa- 
nying I.MPLE.MENTATION .MODULE. Each Object can also be defined and coded in 
a separate pair of DEEINITION MODULE and I.MPLE.MENTATION MODULE. 
To begin a .MODSI.M simulation, the best approach is the definition of all variables and 
types, that are used in several objects, in an initial DEFINITION MODULE "Global", 
followed by the definition and implementation of all necessary objects with their attri- 
butes and the methods they can perform. 
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1. Global Variables and T 5 pes 

This is the place to define all fixed parameters listed in Table 3 on page 21. 
Pertaining to the variable parameters listed in Table 4 on page 22, we can define the 
parameters R 2 , and R^c, w'hich will be controlled by the future user to obtain the re- 
spective value for the decision criterion, the Achievable Average System Availability (see 
also VI. C.), and which will be knowm (or simply set to zero) at the begin of the 

decision process. 

In the Type Declaration the known but fixed values for different object fields 
are set. As an example, the field "Status", defined in Component-Object, is limited to the 
values "operating", "pausing", "broken" and "standby". Declaring this Type in "Global" 
ensures that no other value for "Status" can be introduced anywhere else, and avoids the 
explicit declaration in each object. 

The DEFINITION MODULE "Global" is shown in Appendix C. 

2. Objects of Weapon System 

We w'ill begin the definition of objects with those needed to model the weapon 
system. The most general module is the Component-Object, having all fields and meth- 
ods most parts of a technical system have as main characteristics. This Component- 
Object has the fields 

• Name - the identifier of the defined component 

• Indent Level - indicates the indenture level of the respective component (Subsystem, 
Assembly, Subassembly or Element) 

• Technology - indicates main field of electronic technology used in the defined com- 
ponent 

• MasterComponent - name of component in next higher indenture level the defined 
component is part of 

• Tenants - name of components in next low^er indenture level which reside inside the 
object (if any) 

• Status - indicates if object is operating, pausing, broken or in stand-by 

• BrokenParts - names of those components at each indenture level that are broken 
and need to be replaced at the appropriate maintenance facility 

• StandBy Avail - indicates if there is a ready-to-start stand-by-component available 

and is able to perform the following methods: 

• ASK METHOD Break - component is informed about an occurred failure within 
its tenants, breaks and passes message and names of broken parts on to its master 
component 
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• ASK METHOD Pause - each component is informed about an occurred failure 
within its Weapon System, and pauses in its aging process until its Weapon System 
is in operating status again 

• TELL METHOD UpAgain - each component is told to resume operational status 
again 



The Element-Object inherits all fields and methods of Component-Object. It has 
four additional fields 

• mean - Mean Time Between Failure 

• alpha - shape parameter a for Gamma distribution of time between failures 

• TimeToFailure - period in simulation time until component fails next time 

• Discard - indicator for irreparable component 

and two additional methods. 

• TELL METHOD ComputeNextFail - the value for field TimeToFailure is com- 
puted 

• ASK METHOD Fail - element is told to fail, and passes message and its own name 
upwards to its master component 

The System-Object inherits all fields of Component-Object, and has four addi- 
tional fields 

• StartDmvnTime - records the point in time at which system failed 

• SuniOfDownTiines - adds (SimulationTime - StartDownTime) to 
SumOfDownTimes at that point in time at which system returns to operational 
status 

• AAerageAvailability - keeps track of the average availability value for its weapon 
system in the simulation 

• Militarj Unit - name of military unit to which the system belongs, 
has one additional method 

• ASK METHOD DownTinie - system is asked to report SumOfDownTimes 

and one method overriding the method with the same name in Component-Object: 

• ASK METHOD Break (0\'ERRIDE) - system is informed about an occurred 
internal failure and orders all of its still operable tenants to pause in the aging 
process 

These three objects are defined and implemented in the module 
"WeaponSystem". The "DEFINITION MODULE WeaponSystem" and the "IMPLE- 
MENTATION MODULE WeaponSystem" are both shown in Appendix D. 
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3. Objects of Maintenance System 

After the definition of the objects needed to model the weapon system, now the 
objects needed to model the maintenance system are defined. The Organizational- 
Maintenance-Object has the fields 

• Name - the identifier of the defined Organizational Maintenance Facility 

• NumberRepairObj’ - the number of Repair-Objects within the Maintenance Facility 

• IdleRepairFacilities - the number of idle Repair-Objects at a point in time 

• IdleFacility - the idle Repair-Object which will be assigned a job next 

• Stock - the list of stock levels for all available spare parts 

• JobQueue - the "waiting for maintenance"-queue 

• ComponentToReplace - the component which will be assigned next to an idle 
Repair-Object 

• ResponsibleIntMaintFac - the name of the next higher Intermediate Maintenance 
Facility 

and is able to perform the following methods; 

• ASK METHOD OrgQueueJob - adds a failed Subsystem to the "waiting for 
maintenance"-queue of an Organizational Maintenance Facility 

• ASK METHOD ReportOfIdle - object is informed about a Repair-Object having 
become idle 

• TELL METHOD Assign - assigns a repair job to the asking Repair-Object 

• ASK METHOD SendToRepair - object is informed that a replaced Subsystem has 
to be sent to the respective Intermediate Maintenance Facility 

The Intermediate-Maintenance-Object inherits all fields and methods of 
Organizational-Maintenance-Object. It has one additional method 

• ASK METHOD IntQueueJob - adds a failed Component to the "waiting for 
maintenance"-queue of an Intermediate .Maintenance Facihty 

and one method overriding the method with the same name in Organizational- 
Maintenance-Object: 

• TELL METHOD Assign - assigns a repair job to the asking Repair-Object, too, 
but applies different administrative and logistic delay times 

These two objects are defined and implemented in the module "Maintenance". 
The "DEFINITION MODULE .Maintenance" and the "I.MPLEMENTATION MOD- 
ULE .Maintenance" are both shown in Appendix E. 
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The Repair-Object is defined independently from the Maintenance-Object, and 
has the following fields; 

• Name - the identifier of the defined Repair-Object 

• MaintUnit - the Maintenance-Object the Repair-Object belongs to 

• MaintLevel - Maintenance Echelon at which jobs are performed at this Repair- 
Object 

• Qual - indicates qualification of Repair-Object for certain fields of electronic tech- 
nology. 

Furthermore, Repair-Object has one method; 

• TELL METHOD Fix - object is told to perform repair 

For the Queue-Object, which will line up and release maintenance jobs following 
the First-In-First-Out (FIFO) policy, the built-in QueueObj can be utilized. 

The Stock-Object just has to keep track of the number of a certain component 
in stock and of the number of eventual reorders that can not be satisfied upon occur- 
rence. It does not have to follow any policy like FIFO or LIFO. It fields are 

• NameOfComp - name of respective Component-Object 

• NanieOfMaintObj - name of .Vlaintenance-Object where Stock-Object is located 

• Allowance - maximum number of components in stock 

• Level - number of components actually in stock at a point in time 

• Ma.xReOrder - maximum number of reorders occurring during simulation run, 

and its methods are 

• ASK METHOD OffStock - decreases actual stock level by one 

• ASK METHOD ToStock - increases actual stock level by one 

• ASK METHOD TrackReOrder - keeps track of the reorders. 
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VIII. EVALUATION AND SUMMARY 



A. PURPOSE OF THE DECISION AID 

As Slated in Chapter I, the main purpose of the decision aid to be developed is ob- 
taining reasonable and, as far as achievable at the relevant point of time within the 
Weapon Acquisition Process, reliable numbers for personal and material quantities, 
which have to be entered into the respective Acquisition Decision Memoranda (ADM). 

B. GENERAL SHORTCOME OF THE DECISION AID 

Though this decision aid tries to model reality as close as possible, its results are 
only as good as the quahty of the input data - a characteristic known as "garbage in, 
garbage out". Due to the origin of the .VITBF-data for all involved Components, the aid 
can not offer absolutely reliable results. To avoid poor results and a feeling of dissatis- 
faction on the user's side, utmost effort has to be concentrated in the building of the data 
base for MTBF- and .MTTR-values (see also VIII.E.l.b.). 

C. ACHIEVEMENT BY TIGER 

Exploiting the multiple features of an introduced simulation program like TIGER, 
and intelligently varying the structure of the input data, an experienced user can obtain 
the following numbers without any modifications to the code of the program (see 
Chapter VI): 

• Upper limit for Average System Availability under consideration of technology and 
general maintenance system 

• Tactically increased upper limit for Average System Availability 

• Technology determined absolute upper limit for Average System Availability 

• Tactically increased technology determined absolute upper limit for Average System 
A vailability 

• MTBF-values for one unit of the System under each of the conditions stated above 

• Technology determined MTBF-Values of all Subsystems 

• Upper limit for Average System Availability at minimum personnel quantity at Or- 
ganizational Maintenance 

• Upper limit for Average System Availability for personnel quantity of 2 and more at 
Organizational Maintenance 

• Upper limit for Average System Availability at maximum personnel quantity at Or- 
ganizational Maintenance 
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• Upper Limit for Spare Parts needed at Organizational Maintenance in the Applied 
War Scenario 

• Upper Limit for Spare Parts needed at the Intermediate Maintenance DES in the 
Applied War Scenario 

• Upper Limit for the Achievable Average System Availability with Zero Stock Allow- 
ance at Organizational Maintenance 

• Upper Limit for the Achievable Average System Availability with Zero Stock Allow- 
ance at all 

• Technology determined MTBF-Values of all Assemblies 

D. PROBLEMS UNDER TIGER 

As shown in Chapter VI, this approach is usable and successful for new Electronic 
Weapon Systems, as long as the following limitations are applicable: 

1. Weapon System will be repaired only in Maintenance Echelon 2 (Organizational 
Maintenance) 

2. The maximum number of Weapon System Units within the responsibility of one 
Organizational Maintenance Facility does not exceed 31. 

These limitations are met by many Weapon Systems to be deployed in the combat 
support and communication forces. They are definitely exceeded by specific material in 
the combat support and communication forces, and by most electronic material de- 
ployed within the combat forces (see II.C.I.). 

The other limitations shown in Table 11 on page 46 (maximum number of Com- 
ponent types = 200, maximum number of distinct Components = 500) generally will 
not impose any problem, because only the rough design structure of the new system is 
known at the point in time this decision aid will be applied. If the information available 
exceeds these limits, the project will have proceeded in the acquisition process, and other 
tools 12 will be applicable and more appropriate. 

E. NECESSARY FUTURE DEVELOPMENTS 

To cover all kind of weapon systems the full scale development of the indicated 
.MODSlM-II-program is inevitable. Three major tasks have to be performed. 



12 like Logistic Support Analysis (LSA) [Ref. 1] 
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1. Development of Data Base 

a. IVeapon System Data 

These data are no problem, they can be obtained from the existing design 

papers. 

b. Component Data 

The most work intensive task (see VII I. B.) will be the development of the 
data base for MTBF- and MTTR-data for components defined by their functional 
characteristics. The evaluation of data for deployed weapon systems can not be per- 
formed on a routine basis; it requires experienced personnel with both a background in 
engineering science, the weapon acquisition process, and in the actual maintenance 
process at the different military’ maintenance facilities. As a rough estimate, at least one 
man-year is necessary’ to build this data base, and a continuing maintenance is manda- 
tory. 

c. Deployment Data 

These data are no problem, they can be obtained from the Mission Need 
Statement (MNS) or an already existing ADM. 

d. Maintenance System Data 

The fixed parameters shown in Table 3 on page 21 are a reasonable, but 
arbitrary estimate of the real world situation. In case of insufficient other information 
they can be applied without causing major deviations. A thorough evaluation of existing 
data might offer more exact data, which might be used to randomize the different delay- 
times in order to introduce even more realism into the model. As a rough estimate, three 
man-months are necessary to build this part of the data base, and a continuing mainte- 
nance is advisable. 

e. Limitations in Personal and Material Quantities 

These limitations are not easily obtained, because all personnel involved will 
try to hide eventually existing realistic values for reasons beyond a pure technical point 
of view. Like the differentiation of component features based on the manufacturing 
contractor {see I11.B.3.), irrational behavior has to be taken into account, once more 
pointing to the need for experienced users. 

2. Development of a Semi-Automated Decision Aid 

The procedure shown in Chapter VI in the application of TIGER was a step- 
by-step off-line process. Each simulation nin had to be initiated by the user, though the 
sequence of input steps was predetermined. Interactions between the user and an on-line 
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simulation program are only necessary’ at the following points (Step numbers and Run 
numbers refer to Chapter VI); 

• After completion of Run 1 to determine the need for the relaxation of tactical re- 
quirements and'or the need for an exceptional spare stock of A-Units at the lo- 
cation of the Organizational Maintenance 

• After completion of Run 2 to determine the number of repair personnel at Organ- 
izational Maintenance sufficient to achieve the required Average System Avail- 
ability 

• After completion of a newly designed Run 3. Run 3 will offer combinations of pos- 
sible numbers of spare parts in stock at Organizational Maintenance (B-Units) and 
in stock at Intermediate Maintenance - both in the Direct Exchange Stock (DES, 
B-Units) and in the general stock (C- and D-Units) - , necessary to offer the Or- 
ganizational Maintenance "unlimited-like" supply. The user has to determine those 
combinations that seem to be realistic, and has to start a newly designed Run 4, 
which finally will offer the number of repair personnel at Intermediate Mainte- 
nance, necessary to refill the stock levels, decided upon after Run 3. 

So the program to be developed in MODSIM can be structured as a four-step 
program, asking for a decision by the user after each step. So no decision - while using 
the decision aid - is made by the program. The program only assists the user with data 
based on an analysis, so eventually gaining acceptance even from decision makers who 
might feel uncomfortable with the idea that their intuitive ideas can be performed by a 
computer. 

3. Integration of Specific Features 

The scope of subtleties that can be integrated into the final decision aid is nearly 
infinite. A trade-off between reality and applicability has to be made in order to prevent 
excessive run times or ridiculous results. 

Just a few specialties seem to be reasonable. Though this listing can not be final, 
the following features (partially also included in the TIGER program) should be in- 
cluded in any further development; 

• Allowable Downtimes - this feature should be available both on the Subsystem- and 
the Assembly-level 

• Stand-By - this feature should be available on all indenture levels 

• Availability of Military Unit - enlarging the scope of availability data might increase 
the acceptance also in the military’ combat community 

• Additional consideration of fractional personnel - without entering the discussion 
about the realization of a 0.4-person this feature offers invaluable information 
about the possibility to combine two "fractional" repair persons for 2 different 
small systems with comparable technology to one "allround-repair-person" for both 
systems. 
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APPENDIX A. SAMPLE INPUT FILE FOR 'TIGER'' 

This appendix contains the second input file for the TIGER Reliability Computer 
Program (Step 1, Run 2). The reasoning for this input file is described in detail in IV.B.2. 

RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 
250 1. 28 1 

1 175. 1 15055. 

51000000000000001 



IISUBASSEMBLY.AOIA 


1327. 


5. 


12SUBASSEMBLY_A01B 


664. 


5. 


13SUBASSEMBLY_A02A 


841. 


5. 


14ELEMENT_A0201 


1523. 


5. 


15ASSEMBLY_A03 


344. 


5. 


21ELEMENT_B0101 


225. 


5. 


23ELEMENT_B0102 


534. 


5. 


25ELEMENT_B0201 


866. 


5. 


26SUBASSEMBLY_B02A 


1167. 


5. 


31ELEMENT_C0101 


544. 


5. 


32ELEMENT_C0102 


732. 


5. 


33SUBASSEMBLY_C02A 


1322. 


5. 


34SUBASSEMBLY_C02B 


1003. 


5. 


35SUBASSEMBLY_C03A 


210. 


5. 


41SUBASSEMBLY_D01A 


375. 


5. 


42SUBASSEMBLY_D01B 


445. 


5. 


43SUBASSEMBLY_D01C 


1127. 


5. 


44SUBASSEMBLY_D02A 


554. 


5. 


45ELEMENT_D0201 


1303 


5. 


46ASSEMBLY D03 


628. 


5. 



3 

9 

9 

9 

9 

1 

9 

7 

5 

9 

7 

9 

4 

9 

5 

9 

8 

5 

3 

2 
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11 


11 




12 


12 




13 


13 




14 


14 




15 


15 




21 


21 


22 


23 


23 


24 


25 


25 




26 


26 




31 


31 




32 


32 




33 


33 




34 


34 




35 


35 


36 


41 


41 




42 


42 




43 


43 




44 


44 




45 


45 




46 


46 





UNLIMITED 


SPARES 




SYSl 1 


4 


999 




SUBSYSTEM. 


_A 


501 


0. 0 


SUBSYSTEM. 


_B 


601 


0. 0 


SUBSYSTEM. 


_C 


701 


0. 0 


SUBSYSTEM. 


_D 


801 


35. 0 


2 510 


11 


12 




2 520 


13 


14 




1 530 


15 






3 501 . 


510 


520 


530 


2 611 


21 


23 





61 



2 


612 


22 


24 




1 


610 


611 


612 




612 


611 








2 


620 


25 


26 




2 


601 


610 


620 




2 


710 


31 


32 




2 


720 


33 


34 




1 


730 


35 


36 


37 


36 


35 








37 


35 








37 


36 








3 


701 


710 


720 


730 


3 


810 


41 


42 


43 


2 


820 


44 


45 




1 


830 


46 






3 


801 


810 


820 


830 


4 


999 


501 


601 


701 801 



* * * End of Input-File * * * 



62 



APPENDIX B. 'TIGER'-OUTPUT FOR SAMPLE INPUT FILE 



This appendix contains the output for the sample input file shown in Appendix A. 
The evaluation of this output is described in detail in IV.B.2. 



****************************** *********************************************** 
**** tiger simulation for reliability, maintainability, and availability **** 



RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 



I I I M I I I I I I I i n l- H ■^ TIGER 8. 20 I I I I I I I I I I I I I M I I I II 
+++4+ NAVSEA 05MR WASHINGTON, DC 20362-5101 +++++4 
n M I M I I I I M M I < (202) 692-2150 I I I I I I I I I I H ^■■ f ^ 4 44 



INTIGER 



(INPUT ECHO) 

INPUT DATA HIGH VALUES 



DURATION 


TYPES 


GROUPS 


EQUIPS 


PH-SEQ 


PH-TYP TRIALS 


15230. 00 


46 


999 


46 


2 


1 250 


OUTTIGER 






PAGE 







RELIABILITY FOR PHASE 


1, 1 


0. 924 


RELIABILITY THRU PHASE 


1 


0. 924 


AVERAGE AVAILABILITY 






AVG. AVAIL. THRU PHASE 


T 


0. 998 


FOR PHASE 


1, 1 


0. 998 


TIME (END OF PHASE) 




175. 000 


INSTANT AVAILABILITY 






INSTANT AVAILABILITY 






AT BEGINTIING 


OF PHASE 


1. 000 


AT END OF 


PHASE 


0. 984 
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RELIABILITY FOR PHASE 


1, 2 


0. 000 


RELIABILITY THRU PHASE 


1 0. 000 


AVERAGE AVAILABILITY 






AVG. AVAIL. THRU PHASE 


1 0. 934 


FOR PHASE 


1, 2 


0. 933 


TIME (END OF PHASE) 


15230. 000 


INSTANT AVAILABILITY 






INSTANT AVAILABILITY 




AT BEGINNING 


OF PHASE 


0. 984 


AT END OF 


PHASE 0. 920 



FINAL SUMMARY STATS PAGE 



SYSTEM FIGURES OF MERIT AFTER 



250 MISSION TRIALS 


MEAN 


STANDARD DEVIATION 






OF THE SAMPLE MEAN 


AT ENT) OF MISSION: 






RELIABILITY 


0. 000 


0. 000 


RELIABILITY LOWER PRECISION LIMIT 






(BASED ON STANDARD DEVIATION CRITERIA) 


0. 000 




INSTANTANEOUS AVAILABILITY 


0. 920 


0. 017 


AVERAGE AVAILABILITY 


0. 934 


0. 000 



ESTIMATES OF LONG-TERM VALUES: 

MEAN TIME BET\v’EEN FAILURES 
MEAN TIME TO REPAIR 
AVAILABILITY 

MISSION PERFORMANCE (FAILURE & REPAIR INFORMATION 
CALCULATED FROM TIGER SIMULATION DATA): 



MEAN 


UP TIME 




72. 3 


6. 150 


MEAN 


DOWN TIME 




5. 1 


6. 150 


MEAN 


REPAIR TIME 




5. 1 


0. 004 


MEAN 


ACTIVE REPAIR 


TIME 


0. 0 


0. 000 


MEAN 


TIME TO FIRST 


FAILURE 


299. 2 


5. 744 



72. 3 
5. 1 
0. 934 



TOTAL NO. OF SYSTEM FAILURES = 49152 
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TABLE FAILURES NUM 



PAGE 



EQUIP FAILURE SUMMARY BY EQUIPMENT NUMBER 

EQUIP. NO. TYPE NO. TOTAL EQUIP. AVG. NO. FAILURES 

FAILURES PER MISSION 



11 


11 


2783 


11 . 132 


12 


12 


5586 


22 . 344 


13 


13 


4430 


17. 720 


14 


14 


2381 


9 . 524 


15 


15 


10792 


43. 168 


21 


21 


16497 


65. 988 


22 


21 


516 


2 . 064 


23 


23 


6900 


27. 600 


24 


23 


85 


0 . 340 


25 


25 


4291 


17. 164 


26 


26 


3122 


12. 488 


31 


31 


6870 


27. 480 


32 


32 


5065 


20. 260 


33 


33 


2742 


10 . 968 


34 


34 


3707 


14. 828 


35 


35 


17652 


70. 608 


36 


35 


294 


1 . 176 


37 


35 


297 


1 . 188 


41 


41 


9966 


39. 864 


42 


42 


8317 


33. 268 


43 


43 


3268 


13. 072 


44 


44 


6738 


26 . 952 


46 


46 


5991 


23. 964 



FGC/EIC 
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128290 



513. 158 



TABLE FAILURES TYPE PAGE 



EQUIP FAILURE SUMMARY BY EQUIPMENT TITE NUMBER 



TYPE 


TOTAL EQUIP. 


AVG. NO. FAILURES 


MAINTENANCE 


STD. DEV. 




FAILURES 


PER MISSION 


HOURS 


MAINT. HRS 


11 


2783 


11. 132 


2. 752 


0. 000 


12 


5586 


22. 344 


5. 544 


0. 000 


13 


4430 


17. 720 


4. 448 


0. 000 


14 


2381 


9. 524 


2. 358 


0. 000 


15 


10792 


43. 168 


10. 816 


0. 000 


21 


17013 


68. 052 


16. 845 


0. 000 


23 


6985 


27. 940 


7. 002 


0. 000 


25 


4291 


17. 164 


4. 305 


0. 000 


26 


3122 


12. 488 


3. 159 


0. 000 


31 


6870 


27. 480 


6. 930 


0. 000 


32 


5065 


20. 260 


5. 057 


0. 000 


33 


2742 


10. 968 


2. 802 


0. 000 


34 


3707 


14. 828 


3. 762 


0. 000 


35 


18243 


72. 972 


18. 168 


0. 000 


41 


9966 


39. 864 


9. 877 


0. 000 


42 


8317 


33. 268 


8. 241 


0. 000 


43 


3268 


13. 072 


3. 344 


0. 000 


44 


6738 


26. 952 


6. 801 


0. 000 


46 


5991 


23. 964 


6. 148 


0. 000 




128290 


513. 158 


0. 019 




TABLE 


SPARES LEVEL 




PAGE 








UNLIMITEE 


1 SPARES 








SUMMARY OF 


SPARES USED 





FGC/EIC 
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1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 



ORGANIZATION SPARES 



INTERMEDIATE SPARES 



DEPOT SPARES 





TOTAL 


USE PER 




TOTAL 


USE PER 




TOTAL 


USE PER 


STOCK 


USED 


MISSION 


STOCK 


USED 


MISSION 


STOCK 


USED 


MISSION 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. OOD 


90000 


2783 


11. 132 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


5586 


22. 344 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


4430 


17. 720 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


2381 


9. 524 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


10792 


43. 168 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


17013 


68. 052 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


6985 


27. 940 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


4291 


17. 164 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


3122 


12. 488 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 • 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 
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30 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


31 


90000 


6870 


27. 480 


90000 


0 


0. 000 


90000 


0 


0. 000 


32 


90000 


5065 


20. 260 


90000 


0 


0. 000 


90000 


0 


0. 000 


33 


90000 


2742 


10. 968 


90000 


0 


0. 000 


90000 


0 


0. 000 


34 


90000 


3707 


14. 828 


90000 


0 


0. 000 


90000 


0 


0. 000 


35 


90000 


18243 


72. 972 


90000 


0 


0. 000 


90000 


0 


0. 000 


36 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


37 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


38 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


39 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


40 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


41 


90000 


9966 


39. 864 


90000 


0 


0. 000 


90000 


0 


0. 000 


42 


90000 


8317 


33. 268 


90000 


0 


0. 000 


90000 


0 


0. 000 


43 


90000 


3268 


13. 072 


90000 


0 


0. 000 


90000 


0 


0. 000 


44 


90000 


6738 


26. 952 


90000 


0 


0. 000 


90000 


0 


0. 000 


45 


90000 


0 


0. 000 


90000 


0 


0. 000 


90000 


0 


0. 000 


46 


90000 


5991 


23. 964 


90000 


0 


0. 000 


90000 


0 


0. 000 


TABLE 


UNAVA NTJM 




PAGE 












R\M 


1/2: NO 


STOCK OF 


A-UNITS; 


ALLOWABLE 


DOWNTIMES 









CRITICAL EQUIPMENT BY EQUIPMENT NUMBER FOR FULL SYSTEM 



UNAVAILABILITY AND 
PERCENT OF UNAVAILABILITY 



NAME 


NUMBER HRS 


ASSEMBLY_A03 


52510. 1094 


ELEMENT.COIOI 


33285. 5586 


SUBASSEMBLY_A01B 


27054. 7500 


ELEMENT_C0102 


24513. 2500 


SUBASSEMBLY_A02A 


21490. 1719 







EQUIP 


EQUIP 


UNAVA 


PERCENT 


TYPE 


NO. 


0. 0138 


20. 81 


15 


15 


0. 0087 


13. 19 


31 


31 


0. 0071 


10. 72 


12 


12 


0. 0064 


9. 71 


32 


32 


0. 0056 


8. 51 


13 


13 



FGC/EIC 



68 



ELEMENT_B0201 


20735. 0859 


0. 0054 


8. 22 


25 


25 


SUBASSEMBLY_C02B 


17946. 0820 


0. 0047 


7. 11 


34 


34 


SUBASSEMBLY_B02A 


15077. 8633 


0. 0040 


5. 97 


26 


26 


SUBASSEMBLY.AOIA 


13427. 8672 


0. 0035 


5. 32 


11 


11 


SUBASSEMBLY_C02A 


13275. 4180 


0. 0035 


5. 26 


33 


33 


ELEMENT_A0201 


11482. 1250 


0. 0030 


4. 55 


14 


14 


ELEMENT_B0101 


620. 3950 


0. 0002 


0. 25 


21 


22 


ELEMENT_B0101 


522. 2812 


0. 0001 


0. 21 


21 


21 


ELEMENT_B0102 


209. 1828 


0. 0001 


0. 08 


23 


23 


ELEMENT_B0102 


108.4651 


0. 0000 


0. 04 


23 


24 


SUBASSEMBLY_C03A 


4. 1523 


0. 0000 


0. 00 


35 


35 


SUBASSEMBLY_C03A 


4. 1523 


0. 0000 


0. 00 


35 


36 


SUBASSEMBLY_C03A 


4. 1523 


0. 0000 


0. 00 


35 


37 


TABLE UNAVA TYPE 




PAGE 








RUN 1/2: NO STOCK 


OF A-UNITS; 


ALLOWABLE 


DOWNTIMES 







CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR FULL SYSTEM 

UNAVAILABILITY AND 





PERCENT 


OF UNAVAILABILITY 












EQUIP 


NAME 


NTJMBER HRS 


UNAVA 


PERCENT 


TYPE FGC/EIC 


ASSEMBLY_A03 


52510. 1094 


0. 0138 


20. 81 


15 


ELEMENT_C0101 


33285. 5586 


0. 0087 


13. 19 


31 


SUBASSEMBLY.AOIB 


27054. 7500 


0. 0071 


10. 72 


12 


ELEMENT_C0102 


24513. 2500 


0. 0064 


9. 71 


32 


SUBASSEMBLY_A02A 


21490. 1719 


0. 0056 


8. 51 


13 


ELEMENT_B0201 


20735. 0859 


0. 0054 


8. 22 


25 


SUBASSEMBLY_C02B 


17946. 0820 


0. 0047 


7. 11 


34 


SUBASSEMBLY_B02A 


15077. 8633 


0. 0040 


5. 97 


26 


SUBASSEMBLY_A01A 


13427. 8672 


0. 0035 


5. 32 


11 



69 



SUBASSEMBLY_C02A 


13275. 4180 


0. 0035 


5. 26 


33 


ELEMENT_A0201 


11482. 1250 


0. 0030 


4. 55 


14 


ELEMENT_B0101 


1142. 6763 


0. 0003 


0. 45 


21 


ELEMENT_B0102 


317. 6477 


0. 0001 


0. 13 


23 


SUBASSEMBLY_C03A 


12.4570 


0. 0000 


0. 00 


35 


TABLE UNREL NUM 




PAGE 







RUN 1/2; NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT NUMBER FOR FULL SYSTEM 

UNTIELIABILITY AND 
PERCENT OF MISSION FAILURES 



DESCRIPTION 


NO. 


UNREL 


PERCENT 


EQUIP 


EQUIP 




FAILURES 






TYPE 


NO. 


ASSEMBLY_A03 


171. 0 


0. 6840 


68. 40 


15 


15 


ELEMENT_C0101 


22. 0 


0. 0880 


8. 80 


31 


31 


ELEMENT_C0102 


13. 0 


0. 0520 


5. 20 


32 


32 


SUBASSEMBLY_C02B 


10. 0 


0. 0400 


4. 00 


34 


34 


SUBASSEMBLY_A01B 


7. 0 


0. 0280 


2. 80 


12 


12 


SUBASSEMBLY_A01A 


7. 0 


0. 0280 


2. 80 


11 


11 


ELEMENT_B0201 


6. 0 


0. 0240 


2. 40 


25 


25 


ELE.MENT.BOIOI 


4. 0 


0. 0160 


1. 60 


21 


21 


SUBASSEMBLY_A02A 


4. 0 


0. 0160 


1. 60 


13 


13 


ELEMENT_B0101 


4. 0 


0. 0160 


1. 60 


21 


22 


SUBASSEMBLY B02A 


2. 0 


0. 0080 


0. 80 


26 


26 



TOTAL NO. MISSION TRIALS = 250 

TOTAL NO. MISSION FAILURES FOR FULL SYSTEM = 250 

TABLE UNREL TYPE PAGE 



FGC/EIC 
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RUN 1/2: NO STOCK OF A-UNITS; ALLOVVABLE DOWNTIMES 



CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR FULL SYSTEM 





UNRELIABILITY 


AND 






PERCENT OF 


MISSION 


FAILURES 




DESCRIPTION 


NO. 


UNREL 


PERCENT 


EQUIP 




FAILURES 






TYPE 


ASSEMBLY_A03 


171. 0 


0. 6840 


68. 40 


15 


ELEMENT_C0101 


22. 0 


0. 0880 


8. 80 


31 


ELEMENT_C0102 


13. 0 


0. 0520 


5. 20 


32 


SUBASSEMBLY_C02B 


10. 0 


0. 0400 


4. 00 


34 


ELEMENT_B0101 


8. 0 


0. 0320 


3. 20 


21 


SUBASSEMBLY_A01B 


7. 0 


0. 0280 


2. 80 


12 


SUBASSEMBLY_A01A 


7. 0 


0. 0280 


2. 80 


11 


ELEMENT_B0201 


6. 0 


0. 0240 


2. 40 


25 


SUBASSEMBLY_A02A 


4. 0 


0. 0160 


1. 60 


13 


SUBASSEMBLY_B02A 


2. 0 


0. 0080 


0. 80 


26 



TOTAL 


NO. 


MISSION 


TRIALS = 


250 




TOTAL 


NO. 


MISSION 


FAILURES 


FOR FULL 


SYSTEM = 250 


TABLE 


UNAVA NUM 






PAGE 



FGC/EIC 



RUN 1/2; NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 



CRITICAL EQUIPMENT BY EQUIPMENT NTIMBER FOR SUBSYSTEM_A 



UNAVAILABILITY AND 
PERCENT OF UNAVAILABILITY 
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NAME 


NUMBER HRS 


ASSEMBLY_A03 


53396. 4375 


SUBASSEMBLY_A01B 


27526. 8477 


SUBASSEMBLY_A02A 


21859. 8164 


SUBASSEMBLY_A01A 


13680. 1523 


ELEMENT_A0201 


11710. 7852 


TABLE UNAVA TY'PE 









EQUIP 


EQUIP 


UNAVA 


PERCENT 


TYPE 


NO. 


0. 0140 


41. 62 


15 


15 


0. 0072 


21. 46 


12 


12 


0. 0057 


17. 04 


13 


13 


0. 0036 


10. 66 


11 


11 


0. 0031 


9. 13 


14 


14 



PAGE 



FGC/EIC 



RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR SUBSYSTEM_A 



UNAVAILABILITY AND 
PERCENT OF UNAVAILABILITY 



NAME 


NUMBER HRS 


UNAVA 


PERCENT 


EQUIP 

TYPE 


ASSEMBLY_A03 


53396. 4375 


0. 0140 


41. 62 


15 


SUBASSEMBLY_A01B 


27526. 8477 


0. 0072 


21. 46 


12 


SUBASSEMBLY_A02A 


21859. 8164 


0. 0057 


17. 04 


13 


SUEASSEMBLY_A01A 


13680. 1523 


0. 0036 


10. 66 


11 


ELEMENT_A0201 


11710. 7852 


0. 0031 


9. 13 


14 


TABLE UNREL NUM 




PAGE 







FGC/EIC 



RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT NUMBER FOR SUBSYSTEM.A 

UNRELIABILITY AND 
PERCENT OF MISSION FAILURES 
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DESCRIPTION 


NO. 


UNREL 


PERCENT 


EQUIP 


EQUIP FGC/EIC 




FAILURES 






TYPE 


NO. 


ASSEMBLY_A03 


218. 0 


0. 8720 


87. 20 


15 


15 


SUBASSEMBLY_A01B 


16. 0 


0. 0640 


6. 40 


12 


12 


SUBASSEMBLY_A01A 


9. 0 


0. 0360 


3. 60 


11 


11 


SUBASSEMBLY_A02A 


7. 0 


0. 0280 


2. 80 


13 


13 



TOTAL NO. MISSION TRIALS = 250 

TOTAL NO. MISSION FAILURES FOR SUBSYSTEM_A = 250 

TABLE UNREL TYTE PAGE 

RUN 1/2; NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR SUBSYSTEM.A 

UNRELIABILITY AND 
PERCENT OF MISSION FAILURES 





DESCRIPTION 


NO. 


UNREL 


PERCENT 


EQUIP 






FAILURES 






TYPE 




ASSEMBLY_A03 


218. 0 


0. 8720 


87. 20 


15 




SUBASSEMBLY_A01B 


16. 0 


0. 0640 


6. 40 


12 




SUBASSEMBLY_A01A 


9. 0 


0. 0360 


3. 60 


11 




SUBASSEMBLY_A02A 


7. 0 


0. 0280 


2. 80 


13 


TOTAL 


NO. MISSION TRIALS = 


250 








TOTAL 


NO. MISSION FAILURES 


FOR SUBSYSTEM.A = 


250 




TABLE 


UNAVA NUM 




PAGE 






RUN 


1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 
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CRITICAL EQUIPMENT BY EQUIPMENT NUMBER FOR SUBSYSTEM.B 

UNAVAILABILITY ANT) 

PERCENT OF UNAVAILABILITY 



NAME 


NUMBER HRS 


ELEMENT_B0201 


21394. 3789 


SUBASSEMBLY_B02A 


15552. 7617 


ELEMENT_B0101 


632. 1204 


ELEMENT.BOIOI 


533. 2466 


ELEMENT_B0102 


213. 4900 


ELEMENT_B0102 


112. 0133 


TABLE UNAVA TYPE 









EQUIP 


EQUIP 


UNAVA 


PERCENT 


TYPE 


NO. 


0. 0056 


55. 52 


25 


25 


0. 0041 


40. 36 


26 


26 


0. 0002 


1. 64 


21 


22 


0. 0001 


1. 38 


21 


21 


0. 0001 


0. 55 


23 


23 


0. 0000 


0. 29 


23 


24 



PAGE 



FGC/EIC 



RUN 1/2: NO STOCK OF A-LTJITS; ALLOWABLE DOWTsTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR SUBSYSTEM_B 



UNAVAILABILITY AND 
PERCENT OF UNAVAILABILITY 



EQUIP 



NAME 


NUMBER HRS 


UNAVA 


PERCENT 


TYPE FGC/EIC 


ELEMENT_B0201 


21394. 3789 


0. 0056 


55. 52 


25 


SUBASSEMBLY_B02A 


15552. 7617 


0. 0041 


40. 36 


26 


ELEMENT_B0101 


1165. 3669 


0. 0003 


3. 02 


21 


ELEMENT_B0102 


325. 5032 


0. 0001 


0. 84 


23 


TABLE UNREL NUM 




PAGE 







RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 
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CRITICAL EQUIPMENT BY EQUIPMENT NUMBER FOR SUBSYSTEM.B 

UNRELIABILITY AND 
PERCENT OF MISSION FAILURES 



DESCRIPTION 


NO. 


UNREL 


PERCENT 


EQUIP 


EQUIP FGC/EIC 




FAILURES 






TYPE 


NO. 


ELEMENT_B0201 


164. 0 


0, 6560 


65. 60 


25 


25 


SUBASSEMBLY_B02A 


67. 0 


0. 2680 


26. 80 


26 


26 


ELEMENT.BOIOI 


9. 5 


0. 0380 


3. 80 


21 


22 


ELEMENT_B0101 


7. 0 


0. 0280 


2. 80 


21 


21 


ELEMENT_B0102 


2. 5 


0. 0100 


1. 00 


23 


23 



TOTAL NO. MISSION TRIALS = 250 

TOTAL NO. MISSION FAILURES FOR SUBSYSTEM_B = 250 

TABLE UNPJ:L TYPE PAGE 

RUN 1/2: NO STOCK OF A-UNTTS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR SUBSYSTEM_B 



UNTIELIABILITY ANT) 
PERCENT OF MISSION FAILURES 



DESCRIPTION 


NO. 




FAILURES 


ELEMENT_B0201 


164. 0 


SUBASSEMBLY_B02A 


67. 0 


ELEMENT.BOIOI 


16. 5 


ELEMENT BO 102 


2.5 



UNREL PERCENT EQUIP FGC/EIC 







TYPE 


0. 6560 


65. 60 


25 


0. 2680 


26. 80 


26 


0. 0660 


6. 60 


21 


0. 0100 


1. 00 


23 
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TOTAL NO. MISSION TRIALS = 250 

TOTAL NO. MISSION FAILURES FOR SUBSYSTE.M_B = 250 

TABLE UNAVA NUM PAGE 

RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT NUMBER FOR SUBSYSTEM_C 

UNAVAILABILITY AND 
PERCENT OF UNAVAILABILITY 











EQUIP 


EQUIP 


NAME 


NUMBER HRS 


UNAVA 


PERCENT 


TYPE 


NO. FGC/EIC 


ELE.MENT_C0101 


34082. 2031 


0. 0090 


37. 35 


31 


31 


ELEMENT_C0102 


25083. 2070 


0. 0066 


27. 49 


32 


32 


SUBASSEMBLY_C02B 


18350. 3398 


0. 0048 


20. 11 


34 


34 


SUBASSEMBLY_C02A 


13590. 7812 


0. 0036 


14. 89 


33 


33 


SUBASSEMBLY_C03A 


4. 1523 


0. 0000 


0. 00 


35 


35 


SUBASSEMBLY_C03A 


4. 1523 


0. 0000 


0. 00 


35 


36 


SUBASSEMBLY_C03A 


4. 1523 


0. 0000 


0. 00 


35 


37 


TABLE UNAVA TYPE 




PAGE 









RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR SUBSYSTEM_C 

UNAVAILABILITY AND 
PERCENT OF UNAVAILABILITY 



NAME 



NUMBER HRS 



UNAVA 



EQUIP 

PERCENT TYPE FGC/EIC 



ELEMENT_C0101 


34082. 2031 


0. 0090 


37. 35 


31 


ELEMENT_C0102 


25083. 2070 


0. 0066 


27. 49 


32 


SUBASSEMBLY_C02B 


18350. 3398 


0. 0048 


20. 11 


34 


SUBASSEMBLY_C02A 


13590. 7812 


0. 0036 


14. 89 


33 


SUBASSEMBLY_C03A 


12. 4570 


0. 0000 


0. 01 


35 


TABLE UNREL NUM 




PAGE 







RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 

CRITICAL EQUIPMENT BY EQUIPMENT NUMBER FOR SUBSYSTEM_C 



UNTIELI ABILITY AND 
PERCENT OF MISSION FAILURES 



DESCRIPTION 


NO. 


UNREL 


PERCENT 


EQUIP 


EQUIP 




FAILURES 






TYPE 


NO. 


ELEMENT.COIOI 


146. 0 


0. 5840 


58. 40 


31 


31 


ELEMENT_C0102 


61. 0 


0. 2440 


24. 40 


32 


32 


SUBASSE.MBLY_C02B 


39. 0 


0. 1560 


15. 60 


34 


34 


SUBASSE.MBLY_C02A 


4. 0 


0. 0160 


1. 60 


33 


33 



FGC/EIC 



TOTAL NO. MISSION TRIALS = 250 

TOTAL NO. MISSION FAILURES FOR SUBSYSTEM_C = 250 

TABLE UNTEL TYPE PAGE 

RUN 1/2: NO STOCK OF A-UNITS; ALLOWABLE DOWNTIMES 



CRITICAL EQUIPMENT BY EQUIPMENT TYPE FOR SUBSYSTEM_C 



UNRELIABILITY AND 
PERCENT OF MISSION FAILURES 
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DESCRIPTION 


NO. 


UNREL 


PERCENT 


EQUIP FGC/EIC 




FAILURES 






TYPE 


ELEMENT.COIOI 


146. 0 


0. 5840 


58. 40 


31 


ELEMENT_C0102 


61. 0 


0. 2440 


24. 40 


32 


SUBASSEMBLY_C02B 


39. 0 


0. 1560 


15. 60 


34 


SUBASSEMBLY_C02A 


4. 0 


0. 0160 


1. 60 


33 



TOTAL 


NO. MISSION 


TRIALS = 


250 


TOTAL 


NO. MISSION 


FAILURES 


FOR SUBSYSTEM_C = 250 


TABLE 


REDM 




PAGE 



RESTRICTED ERLANG DISTRIBUTION MODEL 



MTBMF = 299. 23 

2ND MOMENT ABOUT ORIGIN = 



97785. 12 



SHAPE =11 Ml = 



17. 26 M2 = 28. 20 



T R-TIGER R-THEO DIFF DIFSQ 



175.00 0.924 0.936 -.012 0.000 

AFB208I VFNTH : PROGRAM INTERRUPT - FLOATING-POINT UNDERFLOW EXCEPTION 

(SEE V. B. 5. ) 

STANDARD CORRECTIVE ACTION TAKEN. EXECUTION CONTINUING. 

15230.00 0.000 0.000 0.000 0.000 
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AVG ABS DIFF=0. 006 



MAX ABS DIFF=0. 012 



SQUARESSUM=0. 000 



APPENDIX C. MODSIM-II-CODE FOR MODULE GLOBAL 



This appendix contains successfully compiled code for the definition of those vari- 
ables and types, that are used in all further definition and implementation modules. The 
program part shoum is the DEFINITION MODULE "Global", which does not need an 
accompanying IMPLE.MENTATION MODULE, because no procedure or method has 
to be defined. 



DEFINITION MODULE Global; 

FROM GrpMod IMPORT QueueObj; 
FROM Debug IMPORT DebugStream; 



VAR 



f Fixed parameters according to Table 3] 



STotal 



: INTEGER; 



SUnit 



INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 



UD 



DC 



UC 



MartA 



REAL; 

REAL; 

REAL; 

REAL; 

REAL; 

REAL; 

REAL; 



MartB 



LDTstock 



LDTDES 

LDTsupply 

ADT2 



ADT3 
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(Variable parameters according to Table 4; stock levels handled by 



StockObj ect ] 
R2 


INTEGER; 


R3D 


INTEGER; 


R3C 


INTEGER; 



(Variable requirement parameter according to Table 5 handled by 
ComponentOb j ect ] 

TYPE 



IndentLeve IType 
StatusType 
MaintLeve IType 
QualType 


= (System, Aunit, Bunit, Cunit, Dunit); 

= (operating, pausing, broken, standby); 

= (Organizational, Intermediate); 

= (Electronic, Optronic, Communication, 

WeaponGuidance, RADAR, LASER, Electrical, 
Mechanical); 



ComponentTypeQueue = QueueObj; 
BrokenPartsTypeQueue = QueueObj; 
IdleRepairTypeQueue = QueueObj; 
Wait ingJobTypeQueue = QueueObj; 
StockTypeQueue = QueueObj; 



END MODULE. 



APPENDIX D. MODSIM-II-CODE FOR MODULE VVEAPONSYSTEM 



This appendix contains successfully compiled code for the three objects necessar\' 
to model the behavior of a four-indenture-level electronic weapon system: 

1. Component-Object 

2. Element-Object 

3. WeaponSystem-Object 

The first program part shown is the DEFINITION MODULE, followed by the accom- 
panying IMPLEMENTATION MODULE. 



DEFINITION MODULE WeaponSystem; 

FROM SimMod IMPORT SimTime; 

FROM RandMod IMPORT RandomObj; 

FROM GrpMod IMPORT QueueObj; 

FROM Maintenance IMPORT OrgMaintObj; 

FROM Global IMPORT ALL StatusType, ComponentTypeQueue , 



ALL IndentLevelType ,ALL QualType, 
BrokenPartsTypeQueue; 



EXPORTTYPE 

CompObj = OBJECT; FORWARD; 
WeaponSystemOb j = OBJECT; FORWARD; 



TYPE 



CompObj = OBJECT 



Name 

IndentLevel 

Technology 

MasterComponent 



STRING; 

IndentLeve IType; 
QualType; 

CompObj ; 
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Tenants 



ComponentTypeQueue; 

StatusType; 

BrokenPartsTypeQueue; 

BOOLEAN; 



Status 



BrokenParts 



StandByAvail 



ASK METHOD Break (IN BrokenParts : BrokenPartsTypeQueue); 

{CompObj is informed about an occurred failure within its 
ComponentTypeQueue, and passes message and the names of the 
broken components at each respective IndentLevel upwards to 
its MasterComponent ] 

ASK METHOD Pause; 

{CompObj is informed about an occurred failure within its 
WeaponSystemObj , and is told to pause in its aging process 
until WeaponSystemObj is up again] 

ASK METHOD UpAgain; 

{CompObj is told to change to Status=operational ) 

END OBJECT; 

ElementObj = 0BJECT( CompObj ) 

mean : REAL; 

alpha : REAL; 

{Gamma distribution for time between failures] 

TimeToFailure : REAL; 

Discard : BOOLEAN; 

TELL METHOD ComputeNextFail; 

{ElementObj is told to calculate its next time to failure] 
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ASK METHOD Fail; 

{ElementObj is asked to fail, and passes message and its own 
name upwards to its MasterComponent } 

END OBJECT; 



WeaponSysteraObj = OBJECT(CompObj ) 



StartDownTime 
SumOfDownTiraes 
AverageAvai lability 
MilitaryUnit 



REAL; 

REAL; 

REAL; 

OrgMaintObj; 



ASK METHOD DownTime (OUT AverageAvailability : REAL); 
{ WeaponSystemObj is asked to report SumOf DownTime} 



OVERRIDE 

ASK METHOD Break (IN BrokenParts : BrokenPartsTypeQueue); 

{WeaponSysteraObj is informed about an occurred failure within 
its ComponentTypeQueue, and orders its entire 
ComponentTypeQueue to pause} 



END OBJECT; 



END MODULE. 



IMPLEMENTATION MODULE WeaponSystem; 



FROM SimMod IMPORT SiraTime; 
FROM RandMod IMPORT RandomObj; 
FROM GrpMod IMPORT QueueObj; 
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FROM Maintenance IMPORT OrgMaintOb j , IntMaintObj; 

FROM Global IMPORT ALL IndentLevelType , ALL StatusType, ALL QualType, 

ComponentTypeQueue , BrokenPartsTypeQueue; 



VAR 

RandomGenerator : RandomObj; 
i : INTEGER; 

OBJECT CompObj; 

ASK METHOD Break (IN BrokenParts ; BrokenPartsTypeQueue); 
BEGIN 

Status : = broken; 

ASK BrokenParts TO Add (SELF); 

IF IndentLevel <> System 

ASK MasterCoraponent TO Break (BrokenParts); 

END IF; 

ENT) METHOD; 

ASK METHOD Pause; 

BEGIN 

Status := pausing; 

Tenants ;= ASK Tenants First(); 

FOR i: =1 TO ASK Tenants numberin 
Status := pausing; 

Tenants := ASK Tenants Next (SELF); 

END FOR; 

END METHOD; 

ASK METHOD UpAgain; 

BEGIN 

Status := operating; 
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END METHOD; 



END OBJECT; 

OBJECT ElementObj; 

TELL METHOD ComputeNextFail; 

BEGIN 

TimeToFailure := ASK RandomGenerator Gamma (mean, alpha); 
Vv’’AIT DURATION TimeToFailure 
END WAIT; 

ASK SELF TO Fail; 

END METHOD; 

ASK METHOD Fail; 

BEGIN 

Status : = broken; 

ASK BrokenParts TO Add (SELF); 

ASK MasterComponent TO Break (BrokenParts); 

END METHOD; 

END OBJECT; 

OBJECT WeaponSystemObj; 

ASK METHOD Break (IN BrokenParts ; BrokenPartsTypeQueue); 

BEGIN 

Status ; = broken; 

StartDownTime := SimTime(); 

Tenants := ASK Tenants First(); 

FOR i: =1 TO ASK Tenants numberin 
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Status := pausing; 

Tenants := ASK Tenants Next (SELF); 

END FOR; 

ASK MilitaryUnit TO OrgQueueJob (SELF); 

END METHOD; 

ASK METHOD DownTime (OUT AverageAvailability : REAL); 

BEGIN 

AverageAvailability := (SimTime() - SumOfDownTimes)/ SimTime(); 
END METHOD; 

END OBJECT; 

END MODULE. 
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APPENDIX E. MODSIM-II-CODE FOR MODULE MAINTENANCE 



This appendix contains successfully compiled code for the two objects necessaiy' to 
model the behavior of the two studied major Maintenance-Echelon-Levels in the 
Three-Level-Maintenance-System of the German Army: 

1 . Organizational-Maintenance-Object 

2. Intermediate-Maintenance-Object 

The Erst program part shown is the DEFINITION MODULE, followed by the accom- 
panying IMPLEMENTATION MODULE. 

DEFINITION MODULE Maintenance; 

FROM WeaponSystem IMPORT CompObj , VeaponSystemObj; 

FROM GrpMod IMPORT QueueObj; 

FROM Global IMPORT ADT2,ADT3,LDTstock,LDTDES,LDTsupply, 



ALL IndentLevelType,BrokenPartsTypeQueue, 
IdleRepairTypeQueue , WaitingJobTypeQueue , 
StockTypeQueue; 



FROM Repair IMPORT RepairObj; 



EXPORTTYPE 

OrgMaintObj = OBJECT; FORWARD; 
IntMaintObj = OBJECT; FORWARD; 



TYPE 



OrgMaintObj = OBJECT 



Name 

NumberRepairObj 

IdleRepairFacilities 

IdleFacility 



STRING; 

INTEGER; 

IdleRepairTypeQueue; 

RepairObj; 
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Stock 



StockTypeQueue; 

WaitingJobTypeQueue; 



JobQueue 



ComponentToReplace : CorapObj; 
ResponsibleIntMaintFac: IntMaintObj; 



j 



INTEGER; 

INTEGER; 



r 



ASK METHOD OrgQueueJob (IN WeaponSystera : WeaponSystemObj ); 

{OrgMaintObj is told to receive a WeaponSystemObj and to queue 
its broken Subsystem into its JobQueue] 

ASK METHOD ReportOfIdle (IN RepairFacility : RepairObj); 

[MaintObj is told to receive a RepairObj and either to assign 
it a job or to queue it into its IdleRepairQueue] 

TELL METHOD Assign (IN RepairFacility : RepairObj; 



(MaintObj is asked to assign a CompObj to the asking RepairObj; 
both the admistrative delay time ADT2 and the respective 
logistic delay time LDTstock / LDTDES / LDTsupply are 
considered within this method] 

ASK METHOD SendToRepair (IN Component : CorapObj); 

{MaintObj is asked by the telling RepairObj that a replaced 
Com pObj has to be sent to the ResponsibleIntMaintFac] 

END OBJECT; 

IntMaintObj = OB JECT( OrgMaintObj ) 

ASK METHOD IntQueueJob (IN Component : CompObj); 

(IntMaintObj is told to receive a CompObj and to queue it into its 
JobQueue; if queued CompObj is first in JobQueue, initiate its 
assignment to the first RepairObj of IdleRepairObjQueue] 



IN ComponentToReplace : CompObj); 
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OVERRIDE 

TELL METHOD Assign (IN RepairFacility : RepairObj; 

IN ComponentToReplace : CompObj); 

{MaintObj is asked to assign a CompObj to the asking RepairObj; 
both the admistrative delay time ADT3 and the respective logistic 
delay time LDTstock / LDTsupply are considered within this method} 

END OBJECT; 

END MODULE. 



IMPLEMENTATION MODULE Maintenance; 

FROM WeaponSystem IMPORT CompObj, WeaponSystemObj ; 

FROM GrpMod IMPORT QueueObj; 

FROM Global IMPORT ADT2 ,ADT3 , LDTstock, LDTDES , LDTsupply , 

ALL IndentLevelType , BrokenPartsTypeQueue , 
IdleRepairTypeQueue , V.’aitingJobTypeQueue , 
StockTypeQueue; 

FROM Repair IMPORT RepairObj; 

OBJECT OrgMaintObj; 

ASK METHOD OrgQueueJob (IN WeaponSystem : WeaponSystemObj); 

BEGIN 

ComponentToReplace := ASK WeaponSystem. BrokenParts Last(); 
r ;= ASK IdleRepairFacilities numberin; 

IF r=0 

ASK JobQueue TO Add (ComponentToReplace); 

ELSE 
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IdleFacility := ASK IdleRepairFacilitiesRemoveO; 

TELL SELF TO Assign (IdleFacility, ComponentToReplace) ; 
END IF; 

END METHOD; 

ASK METHOD ReportOfIdle (IN RepairFacility ; RepairObj); 

BEGIN 

j : = ASK JobQueue numberin; 

IF j=0 

ASK IdleRepairFacilities Add (RepairFacility); 

ELSE 

ComponentToReplace := ASK JobQueue Remove(); 

TELL SELF TO Assign (RepairFacility, ComponentToReplace); 
END IF; 

END METHOD; 

TELL METHOD Assign (IN RepairFacility : RepairObj; 

IN ComponentToReplace : CompObj); 

BEGIN 

TELL RepairFacility TO Fix (ComponentToReplace); 

END METHOD; 

ASK METHOD SendToRepair (IN Component : CompObj); 

BEGIN 

ASK ResponsibleIntMaintFac TO IntQueueJob (Component); 

END METHOD; 

END OBJECT; 

OBJECT IntMaintObj; 

ASK METHOD IntQueueJob (IN Component : CompObj); 
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BEGIN 

ComponentToReplace ;= ASK Component. BrokenParts Last(); 
r := ASK IdleRepairFacilities numberin; 

IF r=0 

ASK JobQueue TO Add (ComponentToReplace); 

ELSE 

IdleFacility := ASK IdleRepairFacilities Remove(); 

TELL SELF TO Assign (IdleFacility, ComponentToReplace); 
END IF; 

END METHOD; 

TELL METHOD Assign (IN RepairFacility : RepairObj; 

IN ComponentToReplace : CompObj); 

BEGIN 

TELL RepairFacility TO Fix (ComponentToReplace); 

END METHOD; 

END OBJECT; 

END MODULE. 
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